[systemd-devel] keyrings and dbus

[Mantas Mikulėnas]

On Tue, Jun 11, 2019 at 1:08 PM Josef Moellers <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.)

A few years ago I have asked one affected kernel subsystem (cifs) to allow
using @u. They had no interest in doing so. I have since then decided to
just give up on being able to use cifs -o multiuser. (See also: GitHub
issue regarding AFS PAGs.)

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.

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