*** Background Info

Please note that although I am reporting this bug against TW 20230324
the bug actually started occurring with builds created roughly
6 to 9 months ago.

I did not submit earlier because I was having trouble with how to best
document the situation to allow you to easily replicate the bug.

After reading the Linux-PAM System Administrators Guide, I come up with
the following steps to document the bug.

I went with most recent TW build in a VM to replicate the problem so
that you could easily do the same in your debugging, however, the
problem occurs on all of my TW installs on other machines which have
been zypper dup'd for years.

There are NO changes to the newly installed system and it is using
the default configuration for everything.

*** Short description of the problem

Based on my test case research it appears that one of the following
is the source of the problem:

1)  Either pam_keyinit.so is not creating the session keyring during
    login or it is somehow created but does not end up attached
    correctly to the user's GUI login session.

2)  cifscreds is not reading/finding the session keyring

*** Research and Steps to Recreate the problem

Perform new TW build 20230324 installation

    As mentioned above this replicates on my other TW machines which
    have been update for years but I used this as a base so that
    all of the default configuration is in place.

    After installation is completed the rest of the steps are performed
    using my joe user logged into KDE and from a konsole prompt.

keyctl show @u

    Keyring
     725340159 --alswrv   1000 65534  keyring: _uid.1000

keyctl show @s

    Keyring
     900237848 --alswrv   1000 65534  keyring: _uid_ses.1000
     725340159 --alswrv   1000 65534   \_ keyring: _uid.1000

cifscreds add -u joe fileserver

    Warning: you have no persistent session keyring. cifscreds keys will
    not persist after this process exits. See pam_keyinit(8).

Since cifscreds says there is no persistent keyring the credentials do not
exist after cifscrds terminates as shown by the following:

keyctl show @s

    Keyring
     900237848 --alswrv   1000 65534  keyring: _uid_ses.1000
     725340159 --alswrv   1000 65534   \_ keyring: _uid.1000


Based on those results it "appears" that either cifscreds is not finding
the session keyring and therefore that is the problem OR pam_keyinit.so
is somehow not creating a new session keyring ( but it seems to be
creating it based on the above ) or it is creating in a way that is not seen by
the cifscreds program.

Since cifsceds is unable to add the user credentials to the session keyring
and have them persist this means that the user cannot access CIFS shares
which have been mounted with the multiuser mount option.

In testing further I tried the following:

Show starting point keyrings again

    keyctl show @u

        Keyring
         725340159 --alswrv   1000 65534  keyring: _uid.1000

    keyctl show @s

        Keyring
         900237848 --alswrv   1000 65534  keyring: _uid_ses.1000
         725340159 --alswrv   1000 65534   \_ keyring: _uid.1000

Create a new session keyring using:

    keyctl session

        Joined session keyring: 446515518

Show keyring state after creating new one

    keyctl show @u

        Keyring
         725340159 --alswrv   1000 65534  keyring: _uid.1000

    keyctl show @s

        Keyring
         446515518 --alswrv   1000  1000  keyring: _ses

Attempt to add credentials to newly created keyring

    cifscreds add -u joe fileserver

    No warning is displayed and credentials are added to the newly
    created session keyring

    keyctl show @s

        Keyring
         446515518 --alswrv   1000  1000  keyring: _ses
         480791877 ----sw-v   1000  1000   \_ logon: cifs:a:192.168.1.1

User joe can now successfully access the mounted multiuser CIFS shares
using the credentials that it retrieves from session keyring.

Note that I did not include the mount steps ( done as root ) because
they are not part of the problem, as the real issue is with the
session keyring not being available when cifscreds is run.

My initial thought that something was wrong with cifscreds, however,
the following test seems to confirm that the actual problem is with
the PAM configuration and how pam_keyinit.so is creating the session
keyring when logging into the KDE GUI.

To perform this test to demonstrate that:

    Reboot the machine to start clean

    Instead of logging into KDE GUI press Ctrl+Alt+F1 to get a console.

    login

    keyctl show @u

        Keyring
         766463839 --alswrv   1000 65534  keyring: _uid.1000

    keyctl show @s

        Keyring
         576175083 --alswrv   1000  1000  keyring: _ses
         766463839 --alswrv   1000 65534   \_ keyring: _uid.1000

    cifscreds add -u joe fileserver

        No warning is displayed and credentials are successfully added

    keyctl show @u

        Keyring
         766463839 --alswrv   1000 65534  keyring: _uid.1000

    keyctl show @s

        Keyring
         576175083 --alswrv   1000  1000  keyring: _ses
         766463839 --alswrv   1000 65534   \_ keyring: _uid.1000
         673617333 ----sw-v   1000  1000   \_ logon: cifs:a:192.168.1.1

    User joe can now successfully access the mounted multiuser CIFS shares
    using the credentials that it retrieves from session keyring.

Since the session keying and cifscreds work correctly from the tty console
but do NOT when you log into the KDE GUI and do the exact same thing it
would appear that something is wrong with how pam_keyinit is creating
the session keyring and it being available in when logging into the GUI.

I have tried varies other tests to see if I could "fix" the default pam
config to resolve the issue which did not work.

As I final test I tried the following:

    NOTE:

        I understand that we should NOT modify the
        /etc/pam.d/common-*-pc files and I only did this as a test
        to see if it resolved the issue and recognize that
        the real fix is/may be something totally different.

    Modify /etc/pam.d/common-session-pc to add the following to the end

        session optional        pam_keyinit.so revoke force

    reboot

    login to KDE gui

    cifscreds add -u joe fileserver

        No warning is displayed and credentials are successfully added

    User joe can now successfully access the mounted multiuser CIFS shares
    using the credentials that it retrieves from session keyring.

Other research

    grep -ir 'pam_keyinit.so' /etc/pam.d/* /usr/lib//pam.d/*

        Shows that it is included in MANY pam config files

    man pam_keyinit.so says

        The pam_keyinit PAM module ensures that the invoking process has a 
        session keyring other than the user default session keyring.

        In order to allow other PAM modules to attach tokens to the keyring,
        this module provides both an auth (limited to pam_setcred(3)
        and a session component.

        The session keyring is created in the module called.

        Moreover this module should be included as early as possible
        in a PAM configuration.

    man cifscreds NOTES say

       The cifscreds utility requires a kernel built with support for the
       login key type.

       That key type was added in v3.3 in mainline Linux kernels.

       Since cifscreds adds keys to the session keyring, it is highly
recommended
       that one use pam_keyinit to ensure that a session keyring is established
       at login time.

*** Conclusion

It appears that the session keyring is being creating improperly during
GUI login such that cifscreds cannot use it, possibly it is not attached
to the correct process ?

This item on kernel org is from 2012 !!!

   
https://patchwork.kernel.org/project/cifs-client/patch/1342704916-2224-1-git-send-email-jlayton@samba.org/

Seems to describe the problem I am seeing and also demonstrated how the issue
does not exist at the tty console ( Ctrl+Alt+F1 ) but did when done from the
GUI ( xfec4 in that case ) they have the same issue I am reporting.

In one of the comments where somebody tested on a fairly stock Fedora 17 they
said

    An excellent question. I see the same behavior on a fairly stock Fedora
    17 host too. I can only assume that the actual desktop session is
    ending up with a different keyring session than gdm had.

It sure seems like that old issue is exactly what I am seeing here since
the Ctrl+Alt+F1 console does not have the issue and the GUI login does.

The bottom line is that something is wrong with the default pam config for
pam_keyinit.so when you log into the KDE GUI such that the session
keyring is not seen/available to cifscreds and adding to
common-session-pc works around the issue for now but may not be the best
solution or could have other security issues.

I suspect that the real solution is to make sure that KDE GUI login has the
session keyring created in the same way and attached to the same process
as the Ctrl+Alt+F1 login.


I am happy to perform any other tests or gather other information just
provide the steps for whatever other information you need.

Hopefully this very detailed bug report provides you with most of the
legwork completed to debug and now we only need the fix created.