* What about a premount/postumount option for mount?
@ 2012-02-11 12:30 Matthias Schniedermeyer
2012-02-28 13:59 ` Karel Zak
0 siblings, 1 reply; 4+ messages in thread
From: Matthias Schniedermeyer @ 2012-02-11 12:30 UTC (permalink / raw)
To: util-linux
Hi
I'm currently determining how i can integrate dm-crypt devices cleanly
with autofs (via a "ghostable" indirect-map, so nothing to exec there).
What would be ideal is setting up the dm-crypt at mount-time and also to
do the teardown immediately after umount.
The first thing should be quite easy to do, even without the help of
mount, and could be e.g. implemented via a udev-script. So that after
pluging in a USB-disc the corrosponding dm-crypt device can be setup,
which afterwards would be automountable.
Alternativly i could use an 'executable' map-type on the autofs-site,
but i don't want to do that because that can't "ghost" (Ghosting shows
all possible directories, which make "Tab completion" and browsing
though a file-dialog possible (for currently NOT mounted sub-directories
in an indirect-map)). But as far as i can tell that is also only a
half-solution, because i there is nothing executed at umount-time, so
automatic teardown still wouldn't work.
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
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
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.
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
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).
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: What about a premount/postumount option for mount?
2012-02-11 12:30 What about a premount/postumount option for mount? Matthias Schniedermeyer
@ 2012-02-28 13:59 ` Karel Zak
2012-02-28 14:44 ` Matthias Schniedermeyer
2012-02-28 23:29 ` Matthias Schniedermeyer
0 siblings, 2 replies; 4+ messages in thread
From: Karel Zak @ 2012-02-28 13:59 UTC (permalink / raw)
To: Matthias Schniedermeyer; +Cc: util-linux
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>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: What about a premount/postumount option for mount?
2012-02-28 13:59 ` Karel Zak
@ 2012-02-28 14:44 ` Matthias Schniedermeyer
2012-02-28 23:29 ` Matthias Schniedermeyer
1 sibling, 0 replies; 4+ messages in thread
From: Matthias Schniedermeyer @ 2012-02-28 14:44 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
On 28.02.2012 14:59, Karel Zak wrote:
> On Sat, Feb 11, 2012 at 01:30:16PM +0100, Matthias Schniedermeyer wrote:
> > 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?
Which is exactly the problem i'm trying to solve:
Moving from loop-aes to dm-crypt, without reencrypting the discs and
retaining "autofs"ability.
The latter, as far as i can determine, is currently not possible without
patching something.
On my test-machine i build a crude version of "premount/postumount". I
did that by "diverting" (A Debian specific package-manager thing)
/bin/mount to /bin/mount.orig (Same for umount) and putting a
shell-script for /bin/mount that checks for /dev/mapper/... and sets it
up on mount and then execs /bin/mount.orig. Same for umount, only it
does the "loopaesClose" after running umount.orig.
This solution works more or less satisfactory, only the robustness isn't
optimal.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: What about a premount/postumount option for mount?
2012-02-28 13:59 ` Karel Zak
2012-02-28 14:44 ` Matthias Schniedermeyer
@ 2012-02-28 23:29 ` Matthias Schniedermeyer
1 sibling, 0 replies; 4+ messages in thread
From: Matthias Schniedermeyer @ 2012-02-28 23:29 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
On 28.02.2012 14:59, Karel Zak wrote:
> 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).
My "ideal" setup is actually the one i have running for loop-aes.
For "autofs"ability i needed something discoverable.
An encrypted loop-aes disc, by itself, has nothing discoverable except
maybe the disc-serial-number. But an USB-enclosure can kill that too.
So i decided leave 4k at the beginne of each disc and install a
dummy-mbr and use the "disk signature" to identify each HDD:
http://en.wikipedia.org/wiki/Master_boot_record
For all my discs i put a 4 byte "name" string into that field.
I then added a udev-script that checks for the signature and adds a
symlink in /dev/disk/by<whatever>/<signature> if a valid signature is
found.
Then i can use that /dev/disk/by... symlink in autofs and the circle
closes because the patched mount-command for loop-aes does the setup of
the encryption-loop-device transparently.
For dm-crypt i'm currently missing the "transparent" setup/tear-down of
the dm-crypt device.
Lastly, and not really relevant here, i have a perl-script running in a
'screen' that get 'kill -HUP'ed by the same udev-script and checks if
there are files in the tmp-dir for the HDD, copies the files, (umount),
verifys the files, updates the inventory and finaly umounts a last time.
So in the end all i have to do is connect a disc, switch it on, wait
till everything is done and switch it off.
(In the past i also had a big USB-Tree of Power-Plugs and
USB-HDD-Enclosures. Back then i only needed to start the distribution
script. Which, in a loop, checked which disc had files to be copied to,
switched the discs on waited for the files to be copied and switched the
disc off ... But that USB-Tree got unstable somewhere around 40 discs,
which meant i about 10 USB-Power-Plugs (4 switches each) and something
around 16 4-Port USB-Hubs when i finally gave up that experiment.)
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-02-28 23:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-11 12:30 What about a premount/postumount option for mount? Matthias Schniedermeyer
2012-02-28 13:59 ` Karel Zak
2012-02-28 14:44 ` Matthias Schniedermeyer
2012-02-28 23:29 ` Matthias Schniedermeyer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.