Re: What about a premount/postumount option for mount?

Karel Zak
2012-02-28T13:59:23Z

On Sat, Feb 11, 2012 at 01:30:16PM +0100, Matthias Schniedermeyer wrote:
> For the umount thing, i think i could use inotify and wait for the
> "umount"-event as inotify fortunately doesn't prevent umount, but that

See:
http://karelzak.blogspot.com/2011/12/monitor-list-of-currently-mounted.html

> works a little against the spirit of autofs, as it only would work once
> (at least in the case of setup by udev).
>
> All "solutions" taste a little strange for me, the udev-solution mainly
> because i would have a dm-crypt "laying" around which may or may not be

It's usually bad idea to call mount (or so) from udev rules (and it's
often topic in udev mailing list).

> used and the automatic tear-down after umount because what if it just
> timed out and i want it to use again would only work with an exec-type
> map where i could to the setup. Only doing the teardown of the dm-crypt
> after the device is unplugged does not sound right to me either, because
> i don't know if that is safe. My question if unplugging a device, with a
> dm-crypt device in existence, is safe was met with silence.
>
> All crutches would not be needed if there was a "premount" and "postumount"
> option/command in mount that could do something "just before mount" and
> "just after umount". Either "per mount" or "always".
>
> I guess the easiest solution would be if mount would check for
> /sbin/mount.premount and execute that before the mount took place, with
> all the commandline parameters passed to the program and the same after
> umount with /sbin/mount.postumount or something like that.

I hope that next week we (I and dm-crypt maintainer) will publish our
libblkasm (block device assemble library) draft. The goal is to have
a shared library that will on demand assemble requested block device
(dm-raid, mdraid, iscsi, loopdev, ...). The subsystem specific stuff
will be in plug-ins (e.g. blkasm-crypt.so).

The plan is to use the library from fsck or mount (or so..).

> This solution would also make for e.g. "loop-aes" more easily usable,
> currently one has to use a patched version of mount/losetup. With a

Do you know that the latest cryptsetup is able to map loop-aes images
by dm-crypt?

> premount/postumount-command/option it would be possible to use an unpatched
> mount-binary and do the loop-aes setup/teardown "somewhere else", which
> would at least alleviate the need for a patched mount command for the
> usecases where there is no interactivity (e.g. with a "cleartextkey" or
> a gpg-key when a usable gpg-agent is running).

Karel

--
Karel Zak <kzak@redhat.com>