On Sat, 2010-07-10 at 14:44 +0200, Jonas Meurer wrote: > you wrote in another mail, that you're working on this. any news about > that? No not recently.
I guess we should first think about how the future of keyscripts and passdev looks like. You know that I've often predicted that they are likely to get rather more complicated than simpler, especially with "modern" stuff like smartcards, fingerprint sensors (which all need their own driver framework), etc. One way is of course chaining of multiple keyscripts,... but I doubt that this is the right way to go. So personally I'd suggest something like the following: - stick with "only one keyscript" per mapping-entry (better would be the name keyloader or something like this, IIRC it does not have to be a script, right?) - specify a way to put arbitrary options in crypttab - no longer provide a dedicated "passdev" script, but make this a helper tool, which can be used by other keyscripts to load files. Reasonable options (see above would be deivce= and pathname=) Why do I tell all this,... well I guess the future of passdev should be that of a helper tool (perhaps even a new package, that cryptsetup depends on) with about the following interface: param1 => pathname of the file to read param2 => optionally, a device where the fs is located, if not take / param3 => a timeout how long the program may run (including waiting for the device to appear perhaps also two separate params for this) stdout => the read file stdin => ignored stdrr => error messages It should be totally read-only,noexec,noatime etc. pp. The problem here is, some filesystems change the fs per defaul even when mounted ro (all ext234 can do this), so one would have to add specific mount options depending on the fs-type. If the device is already mounted, it should use that. Best would be of course to bind mount then,.. with ro,noexec,etc (as above). But IIRC; bind-mounting simply uses the same options as the original mountpoint. Nevertheless,... I personally do not see much pressure in that issue... it's just a nice functionality... and we have many issues which can be security critical. Best wishes, Chris. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
