[systemd-devel] Thoughts about /etc/crypttab keyscript options

[Lennart Poettering]

On Thu, 14.08.14 20:10, Marc Haber (mh+systemd-devel at zugschlus.de) wrote:

> > Not aware of an C++ code. There's a vala one, and of course the one we
> > ship in systemd itself in C, but c++ i cannot help you with, sorry.
> 
> Is it possible to write a PasswordAgent in shell? Example code please
> ;)

Probably possible, after all bash allows you to talk to unix sockets and
stuff. And you could probably put the protocol together with carefully
crafted echo lines, but I know of nobody who has done that so far...

> > I fear I don#t have an easy suggestion. What kind of device do you
> > actually want to make work here? some smartcard or so?
> 
> That's the vision, yes. At the moment, my keyscript unlocks a small
> LUKS partition on the disk and takes the key for the root fs from
> there. That's just a placeholder for a future more complicated setup.

Not following. You place a key for a LUKS partition on another LUKS
partition? What's the benefit of that? Inception? ;-)

> With Debian's initramfs, unlocking the small LUKS partition works
> transparently even with plymouth. This is real functionality being
> lost in the systemd migration.

Haven't understood your setup yet I must say, before I can agree that
this is "real functionality"...

> > I think in the long run we should somehow work towards the direction to
> > make things like that just work, for common devices like smartcards and
> > other auth tokens...
> 
> First step to do that would be to implement support for the keyscript=
> option in /etc/crypttab as this is the canonical place to hook into on
> non-system systems. At least it's the case on Debian, I don't know
> about Red Hat, Fedora and other distributions.

Well, I am really not convinced that this is a well-defined
interface. Even in your case you have to wait for two devices at least,
right? a synchronous shell callout won't solve that for you since
there's no guarantee that the second LUKS device has already shown up,
or am I missing something?

Shell callouts always appear simply or powerful, but when it comes to
waiting for devices, and executing things as things pop up its often
really not the right tool.

As mentioned we really should redesign the whole thing around the kernel
keyring anyway, I am really conservative in adding support for Debian's
keyscript thingy upstream now. (That of course shouldn't stop Debian
from adding this downstream)

> The PasswordAgent stuff is really neat, but complicated due to the
> socket communication, and it's far from being a drop-in replacement.

Well, it's really easy in C I figure, but admittedly not in shell...

Lennart

-- 
Lennart Poettering, Red Hat