Originally-reported-at: https://github.com/systemd/systemd/issues/1299 (Sigh. Let's play bug ping-pong.) So I am mounting various cifs filesystems with -o multiuser, and storing the password in the kernel keyring (cifscreds &c). But now certain parts of my X11 session are run via systemd, via a separate PAM stack, and thus have their own session keyring – independent from the other half of my X11 programs. (Which, by the way, isn't exactly a new issue – urxvtd, tmux, emacs-daemon, screen would all have the same problem.) As in the original bug report [linked above], I'm told that cifs.ko & cifs-utils should use the 'user' keyring instead of the 'session' one to avoid such problems: > Right, separating sessions from each other makes no sense security-wise on any usual workstation setup. Tools should switch to user-owned data instead of session-speficic data. The concept of sessions is not meant to carry any credentials or other data, it is only the user who owns everything. Another way, I think, would be to "join" an existing named session keyring when logging in to X11 – I remember having seen this option in `keyctl session …`.
Ubuntu 24.04.3 GNOME and Kubuntu 24.04.3 KDE Plasma I'm experiencing what seems to be the same issue with pam_cifscreds.so cached credentials being inaccessible and thus users not being able to access multiuser-mounted CIFS shares on my NAS when running in a GUI environment (KDE or GNOME). When I login via SSH it works correctly and the shares are accessible. pam_cifscreds.so is referenced in /etc/pam.d/common-auth and /etc/pam.d/common-session, both of which are referenced in login, sshd, gdm-password, and sddm. I have enabled debug on pam_cifscreds.so in common-auth and common-session and I can see via journalctl that with both SSH and GUI the credentials are being added, but when I check the keyring, I only see the credentials if I login via SSH. SSH From journalctl Dec 20 20:15:12 host sshd[1964]: pam_cifscreds(sshd:auth): password stored Dec 20 20:15:12 host sshd[1964]: pam_unix(sshd:session): session opened for user user1(uid=1000) by user1(uid=0) Dec 20 20:15:12 host sshd[1964]: pam_cifscreds(sshd:session): credential key for \\192.168.1.1\user1 added From keyctl show Session Keyring 415309542 --alswrv 1000 1000 keyring: _ses 952559328 --alswrv 1000 65534 \_ keyring: _uid.1000 423201630 ----sw-v 0 0 \_ logon: cifs:a:192.168.1.1 GUI From journalctl Dec 20 20:22:09 host sddm-helper[1766]: pam_cifscreds(sddm:auth): password stored Dec 20 20:22:09 host (systemd)[1770]: pam_unix(systemd-user:session): session opened for user user1(uid=1000) by user1(uid=0) Dec 20 20:22:10 host sddm-helper[1766]: pam_cifscreds(sddm:session): credential key for \\192.168.1.1\user1 added From keyctl show Session Keyring 122429533 --alswrv 1000 1000 keyring: _ses 418921560 --alswrv 1000 65534 \_ keyring: _uid.1000 If I run the cifscreds utility in the GUI environment after logging in to add the CIFS credentials manually, everything works correctly. I believe this issue is related to the switch from having the pam-authenticated user session launch dbus-daemon to having systemd --user launch dbus-daemon. As I understand it (from various websites), historically, the display manager (e.g., gdm, sddm) established a PAM session, created a session keyring via pam_keyinit, then launched the dbus-daemon, ensuring all user programs shared the same keyring. With systemd --user, the dbus-daemon is launched independently through its own PAM stack, resulting in a separate session keyring. This creates a disconnect with the credentials stored in one session keyring (e.g., by pam_cifscreds during login) being inaccessible to bus-activated programs that belong to a different session (systemd --user) and thus have a different session keyring. I have found several conversations (including those linked above) about this issue dating back some 10 years as this change apparently affects not only CIFS, but AFS, kerberos, and other services that use the session keyring to share credentials. Some applications have moved to using the user keyring instead of the session keyring to improve compatibility, particularly in environments like systemd user instances where session keyrings are isolated. This shift is also aligned with recommendations from systemd developers to use the user keyring for better containerization and user-space isolation. As I understand it, there may be a corresponding patch that needs to be made in the kernel as well. What I'm trying to accomplish is when different users login, the shares they have access to are automatically mounted with permissions appropriate for their account without them having to jump through hoops to make it happen. I have been using Ubuntu for over seven years and have never encountered this issue, but I've always been running on servers in a terminal environment. I'm now in the process of switching desktop environments from Windows to Linux and ran into this issue almost immediately. I have not been able to find a workaround that doesn't involve users having to enter their password multiple times (once to login, then once for each device hosting CIFS shares), every time they login to their desktop environment. Through my research I came across this bug report from 2015, but its status is listed as NEW. Is there any work underway to address this issue?