[pkg-cryptsetup-devel] Bug#509068: Bug#509068: cryptsetup: improve passdev, that it also works when the device is already mounted

[Christoph Anton Mitterer]

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.