why isn't pam_mount's /sbin/mount.crypt part cryptsetup ?

[GoogleCodeExporter]

mount.crypt (from pam_mount) is very handy (and "promising"):

It supports mount options on top of which it adds:
- crypto_name (the name of the device mapper to be used)
- keyfile
- and a couple of other crypto-related options.

Up to know and AFAIK, several distributions use init-script with home made 
initialization and custom /etc/*crypt* files.
(/etc/cmtab (Debian), /etc/crypttab (Gentoo), + /etc/{default,conf.d} files)

Adding this crypto_name option, mount.crypt fills the gap between /etc/fstab 
(where most of the configuration occurs) and device-mapper and crypto options, 
while adding most of the crypto-configuration-power à la fuse.
(fuse + /etc/fstab already allows mounting a huge variety of filesystem without 
messing so much with /etc-wide configuration)

mount.crypt relies a lot on libcryptsetup in order to mount devices but it 
seems a bit strange that it's not part of the cryptsetup package itself.

- A possible explanation is that mount.crypt currently does custom parsing of 
files instead of using libmount. This would need to be rewritten (as could be 
questioned the use of hxtools)

- Another possible explanation is that mount.crypt is currently based on the 
/run/cmtab w.r.t cryptmount.

About /run/cmtab, there are 3 possibilities:

1) either libmount *can* keep track of every options (including luks/dm data) 
and in that case crypto_name is trackable through /proc/mounts|libmount thus 
/run/cmtab isn't useful anymore
(https://www.kernel.org/pub/linux/utils/util-linux/v2.21/libmount-docs/libmount-
Option-maps.html could be this !)

2) either libmount could not provide us with the original crypto information 
from cryptsetup, and then:
2.1) the cmtab file needs to be handled manually (which IMHO is highly 
undesirable)
2.2) dm ioctl (`dmsetup info`/`cryptsetup status`/`losetup -a`) are viable and 
exhaustive sources for the same information

Would a libmount based mount.crypt be in the scope of the cryptsetup package, 
would it be desirable ?

Original issue reported on code.google.com by raphael....@gmail.com on 24 Mar 2014 at 2:00

[GoogleCodeExporter]

Replying to myself about the libmount ability to store "abritrary" data:
/run/mount/utab could contain an ATTRS= string set by mnt_fs_get_attributes()
libmount also provides mnt_table_get_userdata() / mnt_table_set_userdata()

Original comment by raphael....@gmail.com on 26 Mar 2014 at 1:34

[GoogleCodeExporter]

I am not a cryptsetup developer,i just though i should respond since its been 
two days and you have not heard anything.

I think the standard response to your question is that cryptsetup is a general 
purpose tool that deals with setting up and tearing down dm-crypt devices and 
it does not concern itself with how the dm-crypt devices are used.

There are tools like the one you mention here among others like 
"zuluCrypt","pmount","cryptmount" that use cryptsetup to do file system 
encryption.

Original comment by mhogomch...@gmail.com on 27 Mar 2014 at 2:34

[GoogleCodeExporter]

Well, I do no think that everything what uses libcryptsetup should be part of 
cryptsetup package. We provide stable API, application just use it.

But anyway, while crypt.mount can be helpful for some use cases, I think much 
more better logic is already used in systemd while it activates arbitrary 
stacked block devices and mount fs on it (including crypt devices). I mean, as 
devices appears, it is able (according to /etc/fstab and /etc/cryptab) activate 
almost every possible storage stack combination. (Please note, I am talking 
about logic, not that systemd is cure for everything.)

The systemd-cryptsetup is also not part of systemd and not cryptsetup and I 
think the same logic applies for pam_mount.

BTW several years ago there was something similar 
(http://people.redhat.com/kzak/util-linux-cryptsetup/).

(But if you think pam_mount is useful, just use it! And yes, libmount is much 
more better to use here. But is was not available in the time pam_mount was 
written.)

In short, sorry, but I think cryptsetup should remain low-level library/utility 
with exactly one use - handle crypt block devices.

Original comment by gmazyl...@gmail.com on 27 Mar 2014 at 6:21

• Changed state: WontFix

[GoogleCodeExporter]

1) systemd ?? autocd is even more better as it works on directory/mount point 
access rather than backing device. It does that for more than a decade, is 
flexible and respect the Unix philosohpy

2) thanks for both the link about util-linux-cryptsetup which could be 
insightful and for the final clarification about the perimeter of cryptsetup.

Original comment by raphael....@gmail.com on 28 Mar 2014 at 1:25