On Thu, Aug 14, 2014 at 08:18:10PM +0200, Lennart Poettering wrote: > On Thu, 14.08.14 20:10, Marc Haber (mh+systemd-de...@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...
There is also the daemonizing and inotify part... > > > 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? ;-) It's actually part of a two-factor-authentification for the poor. The part to know is the key to the LUKS parition, the part to have is an USB key. The key script hashes part of the key found on the USB key and part of the key found on the LUKS partition on the hard disk together to build the actual key to unlock the root fs. I use this scheme for so long that I don't even remember why I implemented it this way, but I guess it was because the logic to unlock a LUKS fs from initramfs was already in place and could be used as-is to unlock the key-part-holding LUKS partition instead of the actual root fs that it was intended for. But I also know of people who use a keyscript to unlock LUKS file systems with the key stored in the system's TPM or on a crypto card. I have never looked into the details of those implementations (having that saved for a long winter night), but I guess that those people will also be pretty hosed on a systemd-based Debian. > > 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? It may be possible that /etc/crypttab is processed sequentially which would obviously not be the case with systemd. So you have a point here. > 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) It didn't occur to me that /etc/crypttab's keyscript= option was a Debianism. I educated myself in the mean time. I'm going to yell at the Debian systemd team now ;-) > > 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... It would be significantly easier if there were boilerplate code to derive from. To a non-adept programmer, adapting the boilerplate would probably lead to enough buffer overflow vulnerabilities anyway ;-) Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel