On Wed, 30.04.14 23:20, Christian Hesse (m...@eworm.de) wrote: > 4. udev launches my executable 'ykfde' > 5. ykfde asks for a second password (second factor) > 6. user types second password on keyboard > 7. ykfde reveives second password and generates challenge > 8. ykfde sends challenge to the key > 9. ykfde receives response from the key > 10. ykfde answers systemd's password request > 11. systemd unlocks the hard disk and continues booting > > Is there any way to make sure the users answers the second password request? > > If no Yubikey is present (and no second password request is started) the user > should be able to answer as usual by typing a valid key.
Did I get this right: a) if there's a yubikey present, your tool shall answer cryptsetup's password queries, and the user shall only answer your tool's questions? b) if there's no yubikey present, the user shall directly answer cryptsetup's password queries? So basically, you want to plug your tool in the middle of the password pipeline, when the tool is running? I don't see a way how to do that in the current scheme. We could extend it in a way where a client could take posession of a password requests or so. Maybe via bsd file locks on the file containing the prompt or so. As soon as some other process sees that it would have to hide the prompt? But meh, I am I have the suspicion we'll revisit the entire password prompt protocol anyway as soon as we have kdbus and can use the bus during early boot... I am not too keen thinking up this just now if we already know that thing will change quite a bit sooner or later in this area... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
