On Thu, Jul 03, 2014 at 01:41:43PM +0200, Lennart Poettering wrote: >On Fri, 27.06.14 01:54, David Härdeman (da...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
