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

[David Härdeman]

On Thu, Jul 03, 2014 at 01:41:43PM +0200, Lennart Poettering wrote:
>On Fri, 27.06.14 01:54, David Härdeman (david at hardeman.nu) wrote:
>
>> Add binary string handling functions and extend the password agent
>> protocol to support binary strings (using "=" as a string prefix
>> instead of "+").
>
>I am feeling a bit uneasy about this one. I have the suspicion that the
>entire password logic should be changed around: we should never transfer
>the passwords in userspace, but use the kernel keyring for this. And the
>queries should probably be triggered via dbus (as soon as kdbus is done,
>and we can use dbus in early-boot). 
>
>THis all makes me want to stay away from this for now. The kernel
>keyring is binary-safe anyway, so half the problem goes away there. The
>kernel also already has a key request API iirc (though a weird one, from
>a cursory look), so we really should align ourselves a lot more with
>that.
>
>Sorry if this sounds disappointing, but I think the proper fix to get
>binary passwords done is the kernel keyring, not just polishing what we
>have right now.

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?

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)?

-- 
David Härdeman