Re: pam_cifscreds, tmux and session keyrings

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

July 22, 2022 2:38 PM, "Mantas Mikulėnas" <grawity@gmail.com> 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