pam_cifscreds, tmux and session keyrings

["Nick Guenther" <nick.guenther@polymtl.ca>]

I have set up pam_cifscreds and multiuser samba mounts for my users, which seemed to work well, until some of my users started complaining that their overnight batch jobs were failing.

The common feature is running their jobs in tmux.

It seems tmux sometimes has access to the keyring that pam_cifscreds uses, but isn't able to put a lock on it. So, only overnight when no one is looking (which is of course the worst time to debug), when mount.cifs's connection drops, it isn't able to reconnect because it has no password available.

I would like to have your wisdom on this situation. Can I configure pam_cifscreds to set a longer expiry on the credentials? Can I put something in tmux's startup script to make it lock in the session keyring? Is this a bug in pam_cifscreds?



Here's the setup:

$ cat /etc/pam.d/sshd
[...]
# Create a new session keyring.
session    optional     pam_keyinit.so force revoke
[...]

$ cat /etc/pam.d/common-session
[...]
session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session optional                        pam_umask.so
session required        pam_unix.so 
session optional                        pam_sss.so 
session optional    pam_cifscreds.so host=duke.neuro.polymtl.ca
session optional        pam_systemd.so 
session optional                        pam_mkhomedir.so umask=0077


$ cat /etc/fstab
[...]
//duke.neuro.polymtl.ca/projects /mnt/duke/projects cifs vers=3.0,nobrl,file_mode=0644,multiuser,credentials=/etc/activedirectory-credentials,nofail,_netdev 0 0
//duke.neuro.polymtl.ca/temp /mnt/duke/temp cifs vers=3.0,nobrl,file_mode=0644,multiuser,credentials=/etc/polygrames-credentials,nofail,_netdev 0 0



Here's a demo:

If someone sshes in, pam_cifscreds stashes their password in the keyring

p115628@davis:~$ keyctl list @s
2 keys in keyring:
452396344: --alswrv 703204575 65534 keyring: _uid.703204575
626459666: ----sw-v     0     0 logon: cifs:a:132.207.65.200

and it forwards their password to the CIFS server so they can access its contents:
 
p115628@davis:~$ ls -l /mnt/duke/projects/pmj/pmj_csa/results.txt 
-rw-r--r-- 1 p115628 domain users 831 Jul  5  2021 /mnt/duke/projects/pmj/pmj_csa/results.txt


Both commands work inside of a tmux session as well.

However if I make a tmux session, _detach_ it, and then log out

p115628@davis:~$ keyctl list @s
2 keys in keyring:
452396344: --alswrv 703204575 65534 keyring: _uid.703204575
293860075: ----sw-v     0     0 logon: cifs:a:132.207.65.200
p115628@davis:~$ tmux
[detached (from session 0)]
p115628@davis:~$ 
logout
Shared connection to davis.neuro.polymtl.ca closed.


and then **wait** for the CIFS connection to time out (or, plan to access the CIFS share that is not yet open) and then back in again:

[kousu@laptop ]$ ssh davis
p115628@davis:~$ tmux attach
p115628@davis:~$ keyctl list @s
keyctl_read_alloc: Key has been revoked
p115628@davis:~$ ls -l /mnt/duke/temp 
ls: cannot access '/mnt/duke/temp': Permission denied
^Bd

But outside of tmux, the connection works, because it has access to the reinitialized keyring:

[detached (from session 0)]
p115628@davis:~$ keyctl list @s
2 keys in keyring:
452396344: --alswrv 703204575 65534 keyring: _uid.703204575
462100230: ----sw-v     0     0 logon: cifs:a:132.207.65.200
p115628@davis:~$ ls -l /mnt/duke/temp 
total 0
drwxr-xr-x 2 p115628 domain users 0 Jun  7 18:10 user1
drwxr-xr-x 2 p115628 domain users 0 Jun 20 18:14 user2


which then makes the share temporarily available inside of tmux as well, at least until it times out again.



Lennart Poettering and co. have the same problem, because `systemd --user` sessions also lose access to the pam_cifscreds keyring: https://github.com/systemd/systemd/issues/1299. They think it's your bug. They offered a fix too, but I want to hear your opinion on it: use user-keyring(7) instead of user-session-keyring(7), or:


diff --git a/cifscreds.c b/cifscreds.c
index 32f2ee4..9ba298d 100644
--- a/cifscreds.c
+++ b/cifscreds.c
@@ -446,7 +446,7 @@ check_session_keyring(void)
        }
 
        /* A problem querying the user-session keyring isn't fatal. */
-       uses_key = keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0);
+       uses_key = keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0);
        if (uses_key == -1)
                return 0;
 
diff --git a/pam_cifscreds.c b/pam_cifscreds.c
index 5d99c2d..3c127bb 100644
--- a/pam_cifscreds.c
+++ b/pam_cifscreds.c
@@ -473,7 +473,7 @@ PAM_EXTERN int pam_sm_open_session(pam_handle_t *ph, int flags __attribute__((un
        }
 
        /* A problem querying the user-session keyring isn't fatal. */
-       uses_key = keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0);
+       uses_key = keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0);
        if ((uses_key >= 0) && (ses_key == uses_key))
                pam_syslog(ph, LOG_ERR, "you have no persistent session "
                                "keyring. cifscreds keys will not persist.");


I see in this old thread https://www.spinics.net/lists/linux-cifs/msg18249.html that you actually want to go the _other_ direction, and isolate your sessions even more:

> > multiuser SMB connections should also be initiated per session, same like the
> > keyring. Currently the cifs SMB connections are accessible also from other all
> > sessions.
>
> That needs to be implemented indeed.

but that doesn't sound like it would make my users happy. In their perspective, tmux should be the same environment as ssh or as the GUI, just more persistent. And I tend to agree.

Anyway, I hope this isn't too intricate or confusing for you. I would really appreciate a second opinion, and maybe a consideration of that patch, if that patch is actually the right answer.

-Nick Guenther
Associé de Recherche
NeuroPoly, Polytechnique de Montréal