Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1 Cannot unmount encrypted filesystems

closed
nobody
None
3
2006-09-17
2006-08-19
Anonymous
No

I can create and mount encrypted filesystem images
successfully with cryptmount, but I cannot unmount
them. When I try to unmount a filesystem (either as
root or as the user that mounted it), I get the
following error message:

$ cryptmount -u private
target "private" does not appear to be mounted

However, the filesystem /is/ still mounted:

$ mount
...
/dev/mapper/private on /home/degraaf/private type ext2
(rw,noexec)

Here are the contents of
/usr/local/cryptmount/etc/cmstatus:

$ cat /usr/local/etc/cryptmount/cmstatus
# auto-generated by cryptmount - do not edit
0
7,private,500

Running strace on cryptmount reveals the following:

$ strace -e trace=open cryptmount -u private
...
open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3
open("/proc/misc", O_RDONLY|O_LARGEFILE) = 3
open("/dev/mapper/control", O_RDWR|O_LARGEFILE) = -1
EACCES (Permission denied)
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
...
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
target "private" does not appear to be mounted

No suspicious messages appeared in syslog or dmesg.

The cryptmount binary and /dev/mapper/control have the
following permissions:

$ ls -l `which cryptmount` /dev/mapper
-rwsr-xr-x 1 root root 119207 Aug 17 22:06
/usr/local/bin/cryptmount*

/dev/mapper:
total 0
crw------- 1 root root 10, 63 Aug 19 11:58 control
brw------- 1 root users 253, 0 Aug 19 11:59 private

cryptmount is using the following configuration:

$ cat /etc/cryptmount/cmtab
private {
dev=/home/degraaf/images/private.fs
dir=/home/degraaf/private/
fstype=ext2
fsoptions=noauto,noexec
cipher=aes-cbc-essiv:sha256
keyfile=/home/degraaf/images/private.key
keyhash=sha256
keycipher=bf-cbc
}

I'm using cryptmount 1.1, compiled from source with the
"--with-libgcrypt" configure flag.

My operating system is Fedora Core 5 Linux, running
kernel 2.6.17-1.2174_FC5 with SELinux disabled. The
filesystem containing the cryptmount executable is
ext3, mounted with default options.

Do you have any idea on what the problem is, or have
any suggestions on how to fix it?

Thanks,
Rennie deGraaf

Discussion

  • RW Penney
    RW Penney
    2006-08-24

    • priority: 5 --> 3
    • status: open --> pending
     
  • RW Penney
    RW Penney
    2006-08-24

    Logged In: YES
    user_id=1226045

    Rennie,
    Thank you for the very detailed bug report.

    I have tried very carefully to reproduce the effect you have
    found, but have found no evidence of a similar problem.

    I have re-run cryptmount's own testing script
    ("mudslinger"), which does an extensive series of
    mount/unmount operations, and separately tried
    creating/mounting/unmounting a filesystem almost identical
    to that described in your message, all under Fedora Core 5
    (x86). All these operations seem to run without any problem
    on my installation (which uses kernel 2.6.15-1.2054_FC5, and
    libdevmapper-1.02.02-3.2).

    Judging by your stack-trace, it appears that the
    libdevmapper library is having difficulty opening
    /dev/mapper/control (which cryptmount only accesses via
    libdevmapper), and the "Failure to communicate..." error
    message looks like it comes from somewhere other than
    cryptmount.

    Overall, I'm not convinced that the problems you're having
    are due to something within cryptmount, and are probably
    more likely caused by something elsewhere on your system.
    Unless you or someone else can provide more evidence/detail
    of what may be causing your problems, I don't think there's
    much more I can do at this stage to assist.
    Best of luck,
    RW Penney

     
  • Rennie deGraaf
    Rennie deGraaf
    2006-09-02

    Logged In: YES
    user_id=707284

    I found the problem. It turns out that it /is/ your code,
    sort of. I had a trailing slash on the "dir" option in
    cmtab - it appears that when mounting the filesystem, the
    trailing slash gets stripped before it goes into /etc/mtab,
    and that when is_mounted() looks for the entry in mtab, it
    uses the original path name with the slash still there. I
    tried putting some other irrelevant junk in mount paths in
    cmtab (such as "/foo//bar", "/foo/./bar", and
    "/foo/../foo/bar/") and got the same results - the
    filesystem would successfully mount, but would not unmount.

    I have opened a bug report (#1550899 -
    http://sourceforge.net/tracker/index.php?func=detail&aid=1550899&group_id=154099&atid=790422\)
    for this issue, and submitted a patch to fix it.

     
  • Rennie deGraaf
    Rennie deGraaf
    2006-09-02

    • status: pending --> open
     
  • RW Penney
    RW Penney
    2006-09-02

    • status: open --> pending
     
  • RW Penney
    RW Penney
    2006-09-02

    Logged In: YES
    user_id=1226045

    As noted in my comments on your bug-report, I don't think
    your patch is a good solution because of the use of the
    'realpath()' system call (for which "mount" has its own
    implementation on security grounds).

    I think the most secure solution is simply to recommend that
    users use only canonicalized paths in their cmtab.

    I don't see much call for supporting device or mount paths
    that include '//', '/./', '../' elements in the cmtab, but
    I'll consider adding a routine that makes cryptmount more
    robust to trailing slashes in directory names.

     
    • status: pending --> closed
     
  • Logged In: YES
    user_id=1312539

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • Hi there, some years later, simliar/same problem:

    $ cryptmount --version
    cryptmount-4.2.1
    $ cryptmount secret
    Target "secret" is already mounted
    $ cryptmount -u secret
    Target "secret" does not appear to be mounted

    $ strace -e trace=open cryptmount -u secret
    ...[snip]...
    /dev/mapper/control: open failed: Permission denied
    Failure to communicate with kernel device-mapper driver.
    Target "secret" does not appear to be mounted

    $ modprobe -l dm*
    kernel/drivers/scsi/dmx3191d.ko
    kernel/drivers/net/ethernet/dec/tulip/dmfe.ko
    kernel/drivers/net/usb/dm9601.ko
    kernel/drivers/media/dvb/dm1105/dm1105.ko
    kernel/drivers/hwmon/dme1737.ko
    kernel/drivers/md/dm-bufio.ko
    kernel/drivers/md/dm-crypt.ko
    kernel/drivers/md/dm-multipath.ko
    kernel/drivers/md/dm-round-robin.ko
    kernel/drivers/md/dm-queue-length.ko
    kernel/drivers/md/dm-service-time.ko
    kernel/drivers/md/dm-snapshot.ko
    kernel/drivers/md/persistent-data/dm-persistent-data.ko
    kernel/drivers/md/dm-mirror.ko
    kernel/drivers/md/dm-log.ko
    kernel/drivers/md/dm-region-hash.ko
    kernel/drivers/md/dm-zero.ko
    kernel/drivers/md/dm-raid.ko
    kernel/drivers/md/dm-thin-pool.ko
    kernel/drivers/firmware/dmi-sysfs.ko
    kernel/ubuntu/dm-raid4-5/dm-raid45.ko