[systemd-devel] [PATCH] [RFC] Add binary password agent protocol

[Lennart Poettering]

On Mon, 14.07.14 15:43, David Härdeman (david at hardeman.nu) wrote:

> No problem. Getting it right is part of the systemd philosophy...that
> sometime takes longer
> 
> Anyhow, I've looked at the in-kernel keyring stuff before. Basically
> userspace can request a key via a syscall (or in-kernel code can do
> pretty much the same thing via a similar function call).
> 
> If the key is missing, a placeholder gets created and /sbin/request-key
> is invoked to fill that placeholder with a proper key. The current
> request-key uses config files under /etc to determine how to handle the
> key request.
> 
> The key can then be properly constructed by the add_key sysctl (to write
> the payload to the key).
> 
> As far as I can tell, this could replace the sockets that are currently
> used in systemd, but not much more. All the information in the ask.xxxx
> files would still need to be conveyed separately (e.g. by still creating
> the ask.xxxx file and providing the path to the file as the callout_info
> in request_key).
> 
> I'm guessing you'd like the dbus API to be a higher-level API that
> userspace can use to get systemd to create the ask.xxxx file and call
> request_key()? Are there any advantages of that redirection over doing
> it straight away in the app?

I'd really like to drop the ask.xxxx files, too, and do that on the bus.

Some bus API, where clients that can't find the password they need in
the kernel keyring can ask for it in a nice way, which is then
dispatched to a number of agents, which will place the key in the
keyring and then notify the client about it.

This piece of infrastructure should probably also be able to persist
specific keys to disk, a bit like gnome-keyring, but much simpler
because it would only be a persistancy frontend for the kernel
keyring. It should then also do both system-level and user-level keyring
handling...

> Also, I guess this means that systemd would have to add a homegrown
> version of /sbin/request-key (external dependencies for early boot does
> not seem to be part of the systemd way of doing things)?

Well, yeah, I figure. I think the API is awful though. In this day and
age we really shouldn't have a kernel callout-to-userspace anymore, but
use something else, like some netlink event or so... But anyway we shuld
be able to hide this away sufficiently. The idea is that we would then
just make this stub binary drop the request on the bus and get nice
interactivity.

Hope this makes some sense.

Lennart

-- 
Lennart Poettering, Red Hat