Adding Shyam to this discussion - interesting questions worth investigating. On Thu, Jul 28, 2022 at 9:50 PM Nick Guenther <nick.guenther@xxxxxxxxxx> wrote: > > 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 -- Thanks, Steve
