[systemd-devel] keyrings and dbus

[Mantas Mikulėnas]

On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers <jmoellers at suse.de> wrote:

> On 11.06.19 12:45, Mantas Mikulėnas wrote:
> > On Tue, Jun 11, 2019 at 1:08 PM Josef Moellers <jmoellers at suse.de
> > <mailto:jmoellers at suse.de>> wrote:
> >
> >     Hi,
> >
> >     We have seen this problem: when you open a gnome-terminal, then the
> >     shell in that terminal will not have the same keyring (created by
> >     pam_keyinit.so) as the one eg in an xterm. This is due to the fact
> that
> >     the xterm ist started by the standard fork/exec mechanism which
> passes
> >     the keyring down to the children and the gnome-teminal (actually
> >     gnome-terminal-server) is started by sending a dbus message to some
> >     instance which the starts the terminal process.
> >
> >     AAMOF the gnome-terminal does not even have a keyring, so if one asks
> >     for it ("keyctl show @s"), it is created on the fly. This causes the
> >     kernel to create a keyring as a "user session keyring" while the
> GNOME
> >     session (and thus the xterm) has a "session keyring".
> >
> >     Has anyone seen this and/or, most important question, does anyone
> have
> >     an idea how to solve this?
> >
> >     I know that, strictly speaking, this is not a systemd question, but
> >     we're trying to probe many sources to see if anyone has a solution.
> >
> >
> > IIRC the usual advice by Lennart is to use the user-wide @u keyring
> > instead of session keyrings. (Programs searching in @s should
> > automatically find credentials added to @u, as pam_keyinit creates the
> > link by default.)
>
> Thanks Mantas,
>
> It's not the fact that the user keyring is missing, which it isn't, but
> it's the fact that a "user session keyring" rather than a "session
> keyring" is produced:
>

That is not what I was talking about...


>
> ssh:
> Keyring
>   69871887 --alswrv   1000   100  keyring: _ses
>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
> -> Session Keyring (_ses) linked to User Keyring (_uid.<UID>)
>
> gnome-terminal-server:
> Keyring
>  219457014 --alswrv   1000 65534  keyring: _uid_ses.1000
>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
> -> User Session Keyring (_uid_ses.<UID>) linked to User Keyring
> (_uid.<UID>)
>    User Keyring is identical with User Keyring in ssh
>
> xterm:
> Keyring
>  633373159 --alswrv   1000   100  keyring: _ses
>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
> -> Session Keyring (_ses) linked to User Keyring (_uid.<UID>)
>    User Keyring is identical with User Keyring in ssh
> -end of output-
>
> I'm not THAT familiar with the keyring mechanism, especially not with
> the actualy usage of them, but I don't know if one application or the
> other might later choke on the top level NOT being a "session keyring"
> but a "user session keyring".
>

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.

The only real issue is that programs won't be able to find *the actual
credentials* that were added to a different keyring.


>
> > You could probably alter pam_keyinit.so to allow joining an existing
> > session keyring (which is IIRC possible in the API). That way your
> > graphical sessions Ipam.d/gdm) would join the same @s created by systemd
> > --user instance (pam.d/systemd-user), which is the same one used by
> > dbus-daemon.
>
> The point is that in the gnome-terminal case, pam_keyinit.so is not
> involved.


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.

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190611/795bfc32/attachment-0001.html>