[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-cifs
Subject:    Re: pam_cifscreds, tmux and session keyrings
From:       "Nick Guenther" <nick.guenther () polymtl ! ca>
Date:       2022-07-29 2:47:24
Message-ID: 0371d16e831be9cd9595c443d142e5fc () polymtl ! ca
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]