[Bug 1209741] New: pam session keyring creating during KDE GUI login not available to cifscreds
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.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
Joe S
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
Joe S
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
Joe S
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
Joe S
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
Joe S
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
Joe S
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
Joe S
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c1
Fabian Vogt
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c3
--- Comment #3 from Joe S
I see that /usr/lib/pam.d/login has pam_keyinit.so before common-session, while /etc/pam.d/sddm has it the other way around. Maybe that makes a difference?
Does it work with xdm?
I just tried it with xdm and it is the same issue as with sddm. (In reply to Thorsten Kukuk from comment #2)
It looks like the common usage on various distros is:
session required pam_loginuid.so session optional pam_keyinit.so ... session include common-session
I just tried modifying /etc/pam.d/sddm, /etc/pam.d/sddm-greeter, and /etc/pam.d/sddm-autologin to switch them to that order and it still has the issue. I reboot after any change and when it does not resolve the issues, I put things back to they way the were before the test. So far the ONLY 2 ways that resolve the issue are 1) Use keyctl session after logging into GUI 2) Modify /etc/pam.d/common-session-pc to add pam_keyinit.so revoke force as the last line. Obviously both of those methods are working around the issue by creating a new session keyring later in the process flow but neither of those is a permanent solution to the problem. Not sure if you looked at the URL from 2012 that seems very similar but one of the comments said: Recompiling 3.4.8 kernel with the patch applied (plus another one mentioned in that patch description) solved the problem - in Xfce session opened from GDM the session keyring exists and "cifscreds add server" works. (And mounting CIFS shares with multiuser option as well.) Since logging in via Ctrl-Alt-F1 does not have the issue and since logging in via the GUI does seem to create a session keyring, could it be that the owning process or location of that keyring is different which is why the Ctrl+Alt+F1 login can use the session keyring and the GUI login cannot ? I'm not up to the task of recompiling the kernel, but it seems like someone that is capable of that could review that OLD patch to see if it was somehow removed from more current kernels which is why the problem is occurring again. It seems pretty clear that the issues is some sort of sequencing issue with the GUI login that is the source of the problem. Possibly someone could debug cifscreds add to see why it is not finding the session keyring that pam_keyinit.so is creating when using the GUI login method but does when using the Ctrl+Alt+F1 login method ? I suspect that would point to exactly what the problem is. Holler if there are other tests you'd like me to try. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
Joe S
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c4
Fabian Vogt
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c5
--- Comment #5 from Valentin Lefebvre
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c6
--- Comment #6 from Joe S
key sessions are managed by the module pam_keyinit.so already mentioned. But when you log from a GUI, dbus-daemon will change the session user keyring. Each Display Manager (gdm for gnome, sddm for KDE, etc...) will used systemd-user in the PAM stack. This is why, the login session keyring is different from the condole login to the gui login. It was previously discussed here [2], by our previous pam maintainer.
Thanks for that very detailed explanation.
To fix that, you can add the module pam_keyinit.so to revoke the key settings manage by d-bus in pam.d/systemd-user. I made a test and it looks to work in session from GUI login. Can you confirm if it works for you also ?
I performed the test, with one change. Instead of modifying /usr/lib/pam.d/systemd-user, I copied it to /etc/pam.d/systemd-user and then made the change there. After logging out and back in, the keyring is there and cifscreds can add to it which is the good news. I don't know if you caught this from my bug report but this all used to work and sometime roughly 9 months or so ago it was broken. Today I dug out the oldest ISO I could find for TW and it was for 2021-02-15 and I created a new VM for testing and installed that build! :-) After the install completed, I added the CIFS mounts to /etc/fstab and mounted the shares. Then on my joe user, with NO changes to pam configs ( or anything else ) I ran cifscreds add -u joe fileserver to add the credentials and then the files on those CIFS mounts worked fine. So clearly something since that point in time was changed which broke all this. 2021-02-15 predates lots of things a short list is.... Is before the usr-bin merges It is using kernel 5.10.16.1 There is no /usr/lib/pam.d the files are in /usr/etc/pam.d and /etc/pam.d systemd-user was only in /etc/pam.d and looked like this account include common-account session required pam_selinux.so close session required pam_selinux.so nottys open session include common-session NOTE That it did NOT contain pam_keyinit.so and yet the secondary keyring was created properly and cifscreds worked! This reinforces the point that "something" in the login stock was broken since then which is the root cause of this issue since it used to work fine. The other part of this all though is that there is another module pam_cifscreds which when added to the pam configuration will cache the Linux users credentials during the login eliminating the need to even use cifscreds. When I replaced my Windows server with a Linux server running TW, once I setup Samba on the Linux Server and all the users using the same smb passwords as they use on Windows, the switch was completely transparent to the Windows clients, their drives are mapped and everything works flawlessly. I am still somewhat shocked that there does not appear to be a simple way for a Linux client to connect to that same Linux server's samba shares and use their Linux credentials in the same way the Windows clients can. cifscreds allows you to do this BUT is dependent on pam_keyinit.so creating the keyring and requires the users to do it each time. pam_cifscreds.so caches up the credentials at login and therefore the users don't have to do it. Your proposed solution ( which seems like the right answer to the initial problem ) makes sense to me, however for some reason now pam_cifcreds.so does not appear to allow having it auto cache the credentials even if I add the correct additional entries to the systemd-user file which we added the pam_keyinit.so too. In my testing I think that the reason is because pam_cifscreds is somehow now storing the cached credentials in the _ses keyring instead of the _uid_ses.1000 keyring. Is there a better way to have a Linux client use cached credentials to access a remote Samba share so that they don't have to enter their password again after logging in ? Thanks for those links. From your second link it says: IIRC the usual advice by Lennart is to use the user-wide @u keyring instead of session keyrings. (Programs searching in @s should automatically find credentials added to @u, as pam_keyinit creates the link by default.) A few years ago I have asked one affected kernel subsystem (cifs) to allow using @u. They had no interest in doing so. I have since then decided to just give up on being able to use cifs -o multiuser. (See also: GitHub issue regarding AFS PAGs.) It seems to me like, if cifs used @u and pam_keyinit_so and pam_cifscreds all used @u then all of these problems would go away. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c10
--- Comment #10 from Joe S
Ok, so we definitely need pam_keyinit.so in the systemd-user PAM service then? Upstream did that ages ago: https://github.com/systemd/systemd/commit/ ab79099d1684457d040ee7c28b2012e8c1ea9a4f
I would say YES since that seems to fix the cifscreds problem and since upstream has made that change and I've seen it in some other distros I test with too. The question is what to do about the pam_cifscreds.so issue ??? pam_cifscreds just adds the users login credentials to the keyring at login so that the user does not need to call cifscreds after logging in. I have been playing around with various attempts to get it working again with systemd-user now including pam_keyinit.so but have been unsuccessful. If you are unfamiliar with pamcifs_creds.so the settings that used to work are quite easy. The following needs to be in the pam config files and the CIFS mounts need to use the multiuser mount option. auth optional pam_cifscreds.so session optional pam_keyinit.so revoke force session optional pam_cifscreds.so host=FILESERVER One important point is that the session optional pam_cifscreds.so host=FILESERVER line was finicky and has wanted to be right after pam_keyinit.so. I tried adding the auth line as the 2nd auth line in systemd-user and adding the session pam_cifscreds.so line to systemd-user after pam_keyinit.so so but that no longer is working. On difference in what used to work is that you are adding pam_keyinit before common-session and the sequence that used to work for me with pam_keyinit AFTer common session: session include common-session session optional pam_keyinit.so revoke force session optional pam_cifscreds.so host=FILESERVER however I tried switching that sequence and it does not work either. I got pretty far with debugging before I reported this bug but we are now getting past my point of my understanding the authentication process and keyrings. Since the pam_cifscreds.so issue is directly related to the pam_keyinit.so issue and the fix you are doing, could we please get someone to debug what is going on with pam_cifscreds after this fix is made? I will do anything that I can to help or answer questions, but debugging that part really needs someone that understands the chain of authentication and the keyrings better than I do. Please let me know what I can do to assist. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c19
--- Comment #19 from Joe S
pam_cifscreds' design won't work anymore unless pam_systemd can somehow transfer the session keyring to systemd --user, which is currently just not possible. The design of kernel keyrings does not allow it.
Auth is performed by the DM service (sddm) but the keyring used by the DE session is created by the systemd-user service.
There are 2 problems going on here and it seems that people are getting them confused. I am not ignoring your comment and don't disagree with it, but, PLEASE put it aside for a second and hear me out. In the current TW config ( before you have added pam_keyinit.so to systemd-user ). I have a configuration which I came up with where cifscreds AND pam_cifscreds are BOTH working! Therefore, it is incorrect to say that it is not possible because it is working right now. :-) The problem with that configuration is that I am modifying pam config files which I really shouldn't be modifying. However, when I remove my custom changes and am just using the default pam config files, then after logging in if you do cifscreds add -u joe FILESERVER you get the following warning: Warning: you have no persistent session keyring. cifscreds keys will not persist after this process exits. See pam_keyinit(8). So the default pam config is broken. That's why I submitted this bug report. The reason it is broken is because of what you stated about the login now being done by systemd-user and your fix of adding pam_keyinit.so to systemd-user does in fact fix THAT issue but in doing so creates a NEW but related problem. After making that change to systemd-user to add pam_keyinit.so you can now login and run cifscreds add -u joe FILESERVER and it does not complain about not having a persistent session keyring and it does store the credentials and you can access the shares. BUT, that creates a NEW problem. Now my custom pam config which used pam_cifscreds to add the login to the keyring so you do not have to do cifscreds add -u joe FILESERVER after logging in no longer works. I have tried adding those custom tweaks to systemd-user which I really thought would work but it does not. I have also played around with them in sddm but that didn't work either. I believe that the reason my custom config works is because it is basically creating a keyring "at or near enough to the end" of the login process such that everything works, similar to how if after logging in you can run keyctl session to start a new session and then cifscreds will also work. So it IS possible to make BOTH cifscreds and pam_cifscreds work, but, it requires hacking the pam config files which people should not be modifying, hence, my desire to find a solution which does not modify those files. The PAM manual for pam_keyinit.so says This module is intended primarily for use by login processes. Be aware that after the session keyring has been replaced, the old session keyring and the keys it contains will no longer be accessible. This module should not, generally, be invoked by programs like su, since it is usually desirable for the key set to percolate through to the alternate context. The keys have their own permissions system to manage this. I have a theory that pam_keyinit.so is included in too many places in the default pam config files and often with revoke and/or force and that the real issue is that because it is being called in so many places, when pam_cifscreds add the keys they are later lost because a pam_keyinit.so call later in the process replaces the keyring. That theory seems to be confirmed by the fact that I do have a WORKING pam config with both cifscreds and pam_cifscreds working but it is only possible because I modified pam config files which I should not be modifying. Does that make sense ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c20
--- Comment #20 from Joe S
(In reply to Joe S from comment #0)
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).
This behavior is pretty strange. I'm wondering why in this case cifscreds keeps insisting in using the session keyring if it knows that is pointless. It could return an error at the very least instead of creating keys that are useless. It might have been better to use the user session keyring instead.
That said I agree that user manager instances should have their own session keyring properly hooked up even though it doesn't sound that useful for user services to share keys at a first glance.
It is possible to get cifscreds and pam_cifscreds working as I have done so and used it like that for MANY months. I believe the default config is broken and that the systemd-user fix is correct to fix THAT issue, however, that creates a new issue and breaks a config that currently does work. Please see my detailed reply to Fabian. There are 2 RELATED issues going on. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c21
--- Comment #21 from Joe S
(In reply to Fabian Vogt from comment #11)
pam_cifscreds' design won't work anymore unless pam_systemd can somehow transfer the session keyring to systemd --user, which is currently just not possible. The design of kernel keyrings does not allow it.
That suggests (again) that cifscreds is using the wrong keyring.
If someone could modify cifscreds and pam_cifscreds to both use the user keyring as you suggest, then the kernel also probably needs to be changed so that when the multiuser mount option is used, it is able to get the keys from the user keyring. Personally, that seems like the right thing to do to me, but I am far from experienced with the kernel. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c22
--- Comment #22 from Franck Bui
That theory seems to be confirmed by the fact that I do have a WORKING pam config with both cifscreds and pam_cifscreds working but it is only possible because I modified pam config files which I should not be modifying.
Could you share these modifications (sorry if you already did and I missed them) ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c23
--- Comment #23 from Franck Bui
Personally, that seems like the right thing to do to me, but I am far from experienced with the kernel.
Same here, that's why I suggested you to discuss with the relevant persons. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c24
--- Comment #24 from Joe S
Could you share these modifications (sorry if you already did and I missed them) ?
I do you one better because I debugged the problem with the default configuration and have come up with fixes which do not require me to hack the pam config files which users should not be modifying. To review....the first issue is that the in the default configuration if you run cifscreds add -u joe FILESERVER after logging into KDE you get the warning about no persistent session. This issue is occurred when the change was was made to switch to systemd for the session. Fabian explained this when he said "The session itself (plasmashell, krunner, all processes started by those) are actually children of the systemd user instance, which is in turn a system service." To fix that issue systemd-user needs to create the session using pam_keyinit. So the first patch is to cp /usr/lib/pam.d/systemd-user to /etc/pam.d/systemd-user and them modify /etc/pam.d/systemd-user to add the following as the last line session optional pam_keyinit.so revoke force debug Ideally the distro will fix this in /usr/lib/pam.d/systemd-user as Fabian has discussed so that the end user will not need to do this. The NEW systemd-user would look like auth required pam_deny.so account include common-account session required pam_selinux.so close session required pam_selinux.so nottys open session required pam_loginuid.so session include common-session session optional pam_keyinit.so revoke force debug ### NEW LINE ADDED So that change should have been made when the switch to systemd was done. However, that is only part of the change. Since systemd-user is now starting the session and has pam_keyinit, we need to also modify /etc/pam.d/sddm because it also has pam_keyinit in it ( which would have been for the configuration BEFORE the switch to systemd ). If that is not removed then you have the situation which I suspect was happening where pam_keyinit was called multiple times with force and revoke and the session key lost the prior values. As per the pam_keyinit docs, it is designed to be called by the login process and the current setup is calling it multiple times during the login process causing the loss of the keys. So the second part of the fix is to remove pam_keyinit.so from /etc/pam.d at the same time that it is added to /usr/lib/pam.d/systemd-user ( or the copy in /etc/pam.d/systemd-user that I used for testing ). That is the end of the default config changes to resolve the issues. The last part is to configure pam_cifscreds and that should now be done in the /etc/pam.d/sddm config file. Here is the new /etc/pam.d/sddm file #%PAM-1.0 auth requisite pam_nologin.so auth include common-auth # # The next line is added so that the users login credentials can be cached # to allow accessing cifs multiuser mount points without having to call # cifscreds -u add joe FILESERVER after every GUI login # auth optional pam_cifscreds.so debug account include common-account password include common-password session required pam_loginuid.so session include common-session # # This line should be DELETED ( I commented it out for now ) because # the keyring initialization should now be done in systemd-user since # systemd is being used for the login process. # # session optional pam_keyinit.so revoke force # # This line is added so that and is part of the credential storing in the # keyring created # session optional pam_cifscreds.so debug host=DADPC The systemd-user changes and the remove of pam_keyinit.so should be part of the default pam configuration AFTER the switch is/was made to use systemd. The pam_cifscreds additional lines should NOT be part of the default pam config but would be added by the admin when they want to use cifs multiuser mount points. After debugging and finding this solution, I updated my TW environment to the latest TW snapshot which was 20230329 and confirmed that everything is still working. With this setup, you "could" issue cifscreds add -u ? FILESERVER after login and not have any issues with a missing persistent keyring, HOWEVER, you do NOT need to because if you include the pam_cifscreds.so configuration in /etc/pam.d/sddm then it will store your login credentials in the keyring and you will be able to access the cifs multiuser mount points that are defined in /etc/fstab. So it seems that all that needs to occur are for a TW build to include the fix to the default pam config to ADD pam_keyinit.so in /usr/lib/pam.d/systemd-user and to DELETE pam_keyinit.so from the /etc/pam.d.sddm file. Since systemd-user is now handling the login and using pam_keyinit.so to create the keyring I would also HIGHLY recommend that the following files also be modified to remove pam_keyinit.so, otherwise the keyring gets created and revoked multiple times during the login process and key values are lost. The other files are which should also be modified to remove pam_keyinit.so now that systemd and systemd-user are doing the login and creating the session keyring are: /etc/pam.d/sddm-autologin /etc/pam.d/sddm-greeter /usr/lib/xdm /usr/lib/xdm-np Fabian, I do not have the knowledge for how to submit those changes for the distro's default pam config but I believe my explanation of what needs to be done and why the current config is pretty clear. Can you PLEASE assist with submitting these changes OR could you PLEASE assist in helping to determine who this needs to be assigned to that could help with their submission? I am available and happy to help with any questions. Thank you for helping to work though this issue. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c25
--- Comment #25 from OBSbugzilla Bot
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c26
--- Comment #26 from Franck Bui
The systemd-user changes and the remove of pam_keyinit.so should be part of the default pam configuration AFTER the switch is/was made to use systemd.
This change has just been submitted to Factory, see comment #25. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c27
--- Comment #27 from Franck Bui
Here is the new /etc/pam.d/sddm file
#%PAM-1.0 auth requisite pam_nologin.so auth include common-auth
# # The next line is added so that the users login credentials can be cached # to allow accessing cifs multiuser mount points without having to call # cifscreds -u add joe FILESERVER after every GUI login # auth optional pam_cifscreds.so debug
Does it still work as expected if you log in via tty2 for example ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c28
--- Comment #28 from Joe S
This change has just been submitted to Factory, see comment #25.
When I looked at the change I see pam_keyinit.so being added to /usr/lib/pam.d/systemd-user But I don't see it being removed from /etc/pam.d/sddm ( or the other ones I suggested ). Since systemd-user and sddm both execute during the login process, systemd-user with that change will create ( using revoke force ) the keyring, but if it is left in /etc/pam.d/sddm then when that is processed after systemd-user since sddm also uses revoke and force then it will replace the keyring that was just created in systemd-user. Surely that cannot be correct ??? Reading the docs it seems that "login" processes would specify pam_keyinit.so with revoke force but other processes should either leave it out or not specify revoke force otherwise the keyring keeps getting replaced. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c29
--- Comment #29 from Joe S
(In reply to Joe S from comment #24)
Here is the new /etc/pam.d/sddm file
#%PAM-1.0 auth requisite pam_nologin.so auth include common-auth
# # The next line is added so that the users login credentials can be cached # to allow accessing cifs multiuser mount points without having to call # cifscreds -u add joe FILESERVER after every GUI login # auth optional pam_cifscreds.so debug
Does it still work as expected if you log in via tty2 for example ?
Yes, "cifscreds add -u joe FILESERVER" works fine from tty. I am using the default /usr/lib/pam.d/login file so since it does NOT contain the calls form pam_cifscreds you MUST run cifscreds there to add the credentials. If I copy /usr/lib/pam.d/login to /etc/pam.d/login and then add the corresponding lines for pam_cifscreds and reboot, then tty can access the multiuser mounted shares without having to call "cifscreds add -u joe FILESERVER". I don't normally use tty unless I am having a system problem or debugging something so I never bothered before trying to add them there. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c30
Franck Bui
But I don't see it being removed from /etc/pam.d/sddm ( or the other ones I suggested ).
That part should be addressed by Fabian I guess (as maintainer of sddm). Fabian ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741
http://bugzilla.opensuse.org/show_bug.cgi?id=1209741#c32
--- Comment #32 from Joe S
Since systemd-user and sddm both execute during the login process, systemd-user with that change will create ( using revoke force ) the keyring, but if it is left in /etc/pam.d/sddm then when that is processed after systemd-user since sddm also uses revoke and force then it will replace the keyring that was just created in systemd-user.
Surely that cannot be correct ???
It is. Otherwise only systemd user services get a session keyring, but not processes started by the session itself. See comment 4.
I'm curious, are you aware of ANY other services/programs which use this session keyring besides pam_cifscreds? -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com