July 22, 2022 2:38 PM, "Mantas Mikulėnas" <grawity@xxxxxxxxx> wrote: > On 2022-07-21 23:45, Nick Guenther wrote: > >> [...] >> 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. > > As another user, I'd expect the keyring search to be done recursively -- start from the session > keyring as now, but follow the link into the user keyring, which is usually present (and isn't that > its whole purpose?) > > Then pam_cifscreds could be told which one to insert keys to, allowing it to be used both ways > depending on needs -- just like how Kerberos or AFS can also have either isolated credentials or > user-wide ones. I've figured out a workaround, but I'm unsure about it and I could really use some advice from people with more insight. I said before that my servers (and yours too) have # cat /etc/pam.d/sshd | grep keyinit session optional pam_keyinit.so revoke force And the problem shows up when I detach tmux, **log out**, log back in and reattach tmux; then I see p115628@davis:~$ keyctl list @s keyctl_read_alloc: Key has been revoked The word 'revoked' was the obvious clue I: just to remove the 'revoke' option and the problem goes away: # cat /etc/pam.d/sshd | grep keyinit session optional pam_keyinit.so force This keeps the session-keyring(7) working even after reattaching. Because it's the **log out** that is disabling the keyring; per pam_keyinit(8) [1]: > revoke > Causes the session keyring of the invoking process to be revoked when the invoking > process exits if the session keyring was created for this process in the first place. This change seems to have solved the immediate complaints from my users. But I don't like overriding the default like this; I assume there's a series of good reasons for using 'revoke' that I don't understand. Would there be interest in switching to KEY_SPEC_USER_KEYRING? Would it be a good idea? Can I assume the kernel CIFS code would need a matching change? [1] https://manpages.ubuntu.com/manpages/focal/man8/pam_keyinit.8.html
