Public bug reported:
Binary package hint: libpam-mount
1. Ubuntu release:
$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04
2. Policy:
$ apt-cache policy libpam-mount
libpam-mount:
Installed: 0.32-4
Candidate: 0.32-4
Version table:
*** 0.32-4 0
500 http://us.archive.ubuntu.com hardy/main Packages
100 /var/lib/dpkg/status
3. I expect that mount.crypt will operate in an atomic fashion; that is,
that it will clean after itself if there is ***ANY*** error which
prevents the mount to go through. This is how mount normally works:
either it succeeds or it fails and does not leave cruft behind.
I expect that mount.crypt will integrate with mount so that "mount -t
crypt" and the corresponding umount will work and so that options passed
to mount will be honored by mount.crypt.
4. What happens: see the following scenarios.
Scenario 1:
1. Check allocated loops:
$ sudo losetup -a
You should not have anything allocated. (Or if you do have loops
allocated, keep that in mind at step 5.)
2. Create an encrypted filesystem container for use with dm-crypt. Make
sure you can mount it manually (i.e. by issuing the losetup, cryptsetup
and mount commands manually).
3. Create an entry in fstab:
encrypted.img whatevermountpoint crypt user,loop 0 0
4. Mounting it as a normal user does not work, despite the presence of
"user" in the fstab:
$ mount whetevermountpoint
mount.crypt: error setting up loop device for /dev/loop1
You have to be root to use cryptsetup!
mount.crypt: error creating
loop: can't delete device : No such file or directory
So execute the following command:
$ sudo mount whatevermountpoint
And intentionally make it fail: do not enter your passphrase. The
output will look like this:
Enter passphrase:
mount: you must specify the filesystem type
mount.crypt: error mounting encrypted.img
5. Check allocated loops:
$ sudo losetup -a
/dev/loop0: [fe02]:361999 ([this will contain the path to your encrypted image])
This /dev/loop0 should not be allocated. (I'm assuming no loops were
already allocated in step 1. If loops were allocated then adjust your
expectations accordingly.)
Scenario 2:
1. Perform a normal mount of your encrypted container. Enter the proper
passphrase, etc so that the mount is successful.
2. Check /etc/mtab, for your container you will find an entry of the
form:
encrypted.img whatevermountpoint ext2 rw,noexec,nosuid,nodev 0 0
Notice that the filesystem is "ext2" rather than "crypt". This is
where the problem is. Because the filesystem is set to ext2 when umount
is issued umount.crypt is NOT called.
3. Issue:
$ sudo umount -t crypt -d whatevermountpoint
$ ls -l /dev/mapper/
You will see in /dev/mapper a stray device which corresponds to your
encrypted container. Calling umount.crypt directly works fine but
umount should work.
Conclusion:
I have encountered three issues: a) the "user" option in fstab is
ineffective when issuing "mount -t crypt" on a mount point which has
"user" as an option; b) mount.crypt fails to clean after itself if a
passphrase is not correct c) after using mount with "-t crypt", umount
will not call "umount.crypt" when unmounting because the filesystem
recorded in mtab is the one inside the encrypted container rather than
"crypt".
I have not filed 3 separate bug reports because I think there is enough
evidence here that the *entire* idea of mount.crypt and umount.crypt
should be rethought. I will note here that there are **other**
problems with mount.crypt but reproducing all the errors I encountered
would take too much time.
Ideally, mount.crypt should be rewritten to be robust and interface
properly with mount. A user would expect "mount -t crypt" to
substantially behave in the same way "mount -t ext3" or "mount -t vfat"
works. If this cannot be ensured, then mount.crypt should not exist.
(Actually, the more I think about it, the more I think mount.crypt
should be removed.)
** Affects: libpam-mount (Ubuntu)
Importance: Undecided
Status: New
--
mount.crypt needs to be redesigned, reimplemented or removed
https://bugs.launchpad.net/bugs/232492
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
