<div dir="ltr"><div dir="ltr">On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers <<a href="mailto:jmoellers@suse.de">jmoellers@suse.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11.06.19 12:45, Mantas Mikulėnas wrote:<br>
> On Tue, Jun 11, 2019 at 1:08 PM Josef Moellers <<a href="mailto:jmoellers@suse.de" target="_blank">jmoellers@suse.de</a><br>
> <mailto:<a href="mailto:jmoellers@suse.de" target="_blank">jmoellers@suse.de</a>>> wrote:<br>
> <br>
>     Hi,<br>
> <br>
>     We have seen this problem: when you open a gnome-terminal, then the<br>
>     shell in that terminal will not have the same keyring (created by<br>
>     pam_keyinit.so) as the one eg in an xterm. This is due to the fact that<br>
>     the xterm ist started by the standard fork/exec mechanism which passes<br>
>     the keyring down to the children and the gnome-teminal (actually<br>
>     gnome-terminal-server) is started by sending a dbus message to some<br>
>     instance which the starts the terminal process.<br>
> <br>
>     AAMOF the gnome-terminal does not even have a keyring, so if one asks<br>
>     for it ("keyctl show @s"), it is created on the fly. This causes the<br>
>     kernel to create a keyring as a "user session keyring" while the GNOME<br>
>     session (and thus the xterm) has a "session keyring".<br>
> <br>
>     Has anyone seen this and/or, most important question, does anyone have<br>
>     an idea how to solve this?<br>
> <br>
>     I know that, strictly speaking, this is not a systemd question, but<br>
>     we're trying to probe many sources to see if anyone has a solution.<br>
> <br>
> <br>
> IIRC the usual advice by Lennart is to use the user-wide @u keyring<br>
> instead of session keyrings. (Programs searching in @s should<br>
> automatically find credentials added to @u, as pam_keyinit creates the<br>
> link by default.)<br>
<br>
Thanks Mantas,<br>
<br>
It's not the fact that the user keyring is missing, which it isn't, but<br>
it's the fact that a "user session keyring" rather than a "session<br>
keyring" is produced:<br></blockquote><div><br></div><div>That is not what I was talking about...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
ssh:<br>
Keyring<br>
  69871887 --alswrv   1000   100  keyring: _ses<br>
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000<br>
-> Session Keyring (_ses) linked to User Keyring (_uid.<UID>)<br>
<br>
gnome-terminal-server:<br>
Keyring<br>
 219457014 --alswrv   1000 65534  keyring: _uid_ses.1000<br>
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000<br>
-> User Session Keyring (_uid_ses.<UID>) linked to User Keyring (_uid.<UID>)<br>
   User Keyring is identical with User Keyring in ssh<br>
<br>
xterm:<br>
Keyring<br>
 633373159 --alswrv   1000   100  keyring: _ses<br>
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000<br>
-> Session Keyring (_ses) linked to User Keyring (_uid.<UID>)<br>
   User Keyring is identical with User Keyring in ssh<br>
-end of output-<br>
<br>
I'm not THAT familiar with the keyring mechanism, especially not with<br>
the actualy usage of them, but I don't know if one application or the<br>
other might later choke on the top level NOT being a "session keyring"<br>
but a "user session keyring".<br></blockquote><div><br></div><div>Only if they do an explicit check for no good reason. AFAIK, other than the name, both kinds of keyrings otherwise behave identically from a program's perspective, and whenever the program asks for @s and there isn't one, the kernel just automatically substitutes @us.</div><div><br></div><div>The only real issue is that programs won't be able to find *the actual credentials* that were added to a different keyring.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> You could probably alter pam_keyinit.so to allow joining an existing<br>
> session keyring (which is IIRC possible in the API). That way your<br>
> graphical sessions Ipam.d/gdm) would join the same @s created by systemd<br>
> --user instance (pam.d/systemd-user), which is the same one used by<br>
> dbus-daemon.<br>
<br>
The point is that in the gnome-terminal case, pam_keyinit.so is not<br>
involved.</blockquote><div><br></div><div>It is. The systemd --user instance (from which dbus-daemon and gnome-terminal-server descend) has its own PAM stack and can call pam_keyinit.so if needed.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>