[systemd-devel] Password agent for user services

[Lennart Poettering]

On Mo, 13.05.19 20:30, Michal Koutný (mkoutny at suse.com) wrote:

> Hello,
> I was pondering a user service that would ask for password via the
> password agent infrastructure (as there is
> systemd-gnome-ask-password-agent it could be quite integrated with the
> desktop environment) as an alternative to saving it in (Gnome) keyring.
>
> Naïve experiment with
>
> > [Service]
> > ExecStart=/usr/bin/systemd-ask-password "What is your pwd?"
>
> lead to
>
> > May 13 19:49:56 host systemd-ask-password[28844]: Failed to query password: Permission denied
>
> Then I read about the password agent API [1] and realized that poor
> agent cannot create the notification file in the watched directory. I
> also noticed the auxiliary agent is not spawned for user services [2].
>
> I'm not that familiar with policy-kit, however, IIUC, it is possible to
> ask unprivileged systemd-gnome-ask-password-agent to provide a password
> for system service. Is that correct?
> What would then prohibit making /run/systemd/ask-password world writable
> to allow unprivileged users to ask for a password?

So, the idea was always that the ask-pw logic is for asking unpriv
users for passphrases for priv infrastructure.

I figure extending the logic to allow unpriv infrastructure asking pws
from the same unpriv users would be ok to add. however, this should be
implemented by introducing $XDG_RUNTIME_DIR/ask-password/ or so, as a
separate per-user dir to add these files to. I figure adding such a
patch that adds that would be ok.

> (I understand the interface is so crude so that it works at early boot
> stages w/out DBus. For the user requests it would perhaps make sense to
> make have a parallel DBus API.)

Yeah, we added this stuff so that we can query passwords without dbus
around in early boot, and dbus still isn't available even now in early
boot. The design also was intended to work without continously running
centralized daemon.

Ideally some infrastructure like PK would supply this mechanism
instead of us btw. Or at least the kernel keyring userspace code woul,
but I still don't see that happening. Hence, maybe the easiest and
most acceptable solution would be to simply extend the ask-pw stuff to
support a per-user concept too...

> Or is there an alternative approach to query interactively passwords for
> user services (e.g. already existing user service that could queried via
> DBus)?

Nothing I was aware of.

Lennart

--
Lennart Poettering, Berlin