http://bugzilla.opensuse.org/show_bug.cgi?id=1209741 Bug ID: 1209741 Summary: pam session keyring creating during KDE GUI login not available to cifscreds Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team@suse.de Reporter: jmscdba@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- *** 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... 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. -- You are receiving this mail because: You are on the CC list for the bug.