Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 56698 - Losetup and util-linux are not crypto aware.
Summary: Losetup and util-linux are not crypto aware.
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact:
: 74776 78544 78550 78552 81574 88510 179866 (view as bug list)
Depends On: 111536 127378
TreeView+ depends on / blocked
Reported: 2001-11-25 12:57 UTC by W. Michael Petullo
Modified: 2007-11-30 22:10 UTC (History)
17 users (show)

Fixed In Version: 2.12-2
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2006-08-26 20:45:41 UTC

Attachments (Terms of Use)
util-linux-2.11y-cryptoapi.patch (deleted)
2003-01-22 07:15 UTC, James Ralston
no flags Details | Diff
Cryptsetup patch vs. util-linux-2.12p-5 (deleted)
2005-04-18 02:29 UTC, W. Michael Petullo
no flags Details | Diff

Description W. Michael Petullo 2001-11-25 12:57:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

Description of problem:
The patch distributed with the Linux kernel crypto patches
( has not been applied
to util-linux and losetup.  This means Red Hat Linux does not support
encrypted loopback filesystems out of the box.  See

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
losetup -e aes /dev/loop0 /etc/cryptfile

Actual Results:  Losetup told me that AES was not supported.

Expected Results:  Losetup should have prompted me for a keysize and
password.  Upon entering the password, the loop device should have been
attached to a plaintext filesystem image.

Additional info:

Comment 1 Elliot Lee 2002-01-04 21:03:07 UTC
There may be export issues I don't know of... I'd rather just get this
integrated upstream.

Comment 2 Elliot Lee 2002-01-29 21:39:44 UTC
I talked to the upstream maintainer - he will probably integrate some sort of
crypto patch into future releases. I'll pull it in at that time.

Comment 3 Elliot Lee 2002-10-13 16:05:50 UTC
*** Bug 74776 has been marked as a duplicate of this bug. ***

Comment 4 Elliot Lee 2002-12-03 22:17:17 UTC
*** Bug 78552 has been marked as a duplicate of this bug. ***

Comment 5 Elliot Lee 2002-12-09 17:56:02 UTC
*** Bug 78544 has been marked as a duplicate of this bug. ***

Comment 6 Elliot Lee 2002-12-09 18:58:59 UTC
*** Bug 78550 has been marked as a duplicate of this bug. ***

Comment 7 Elliot Lee 2002-12-09 19:29:32 UTC
Upstream maintainer says this will be resolved in util-linux-2.12.

Comment 8 James Ralston 2003-01-20 05:24:11 UTC
Please reconsider this decision.

Recent Red Hat Linux kernels (2.4.18-17.* at least, perhaps even earlier ones)
already have the CryptoAPI patch installed.  I heavily doubt the Red Hat kernel
package maintainers would've put the CryptoAPI patch in if there were export
issues that Red Hat hasn't already taken care of.

Waiting for util-linux-2.12 is a poor option, for the simple reason that strong
cryptography is something that is useful (necessary, for many people) *now*, and
there's no telling when util-linux-2.12 will be released.

(I mean, for Pete's sake, this bug report was initially filed against Red Hat
Linux *6.2*.  There have been 5 (soon to be 6) Red Hat Linux releases since
then, and there's still no CryptoAPI support in util-linux.)

Another way to look at it: if util-linux-2.12 happens sooner rather than later,
then that minimizes the number of Red Hat Linux releases for which Red Hat has
to maintain the patch.  If util-linux-2.12 happens later rather than sooner,
then that still justifies Red Hat applying the CryptoAPI patch to 2.11, because
otherwise Red Hat's customers would've have to wait too long to get a
CryptoAPI-aware util-linux.

While I'm (of course) not familiar with Red Hat's release schedule, I would hope
that if you act quickly, you could apply the CryptoAPI patch to util-linux and
get it included in the Phoebe test cycle, so that 8.1 (or whatever it's called)
has CryptoAPI support out-of-the-box.

Finally, there's even a handy-dandy patch to do exactly what is required:

(I've been using this patch since 8.0 came out, and I haven't yet encountered
any problems with it.)

Comment 9 Need Real Name 2003-01-20 09:31:36 UTC
Go, man, go.  Use the "handy-dandy patch to do exactly what is required", we 
know how easy patches are to add to SRPM's; dead easy.

Do it, man, do it.

Ralston says's he USING that patch; that makes it a last-half-hour-before-lunch 
type of job.


Comment 10 James Ralston 2003-01-22 07:13:17 UTC
I just installed Phoebe version 2, and needed to get to my encrypted partitions,
so I updated the CryptoAPI patch for util-linux-2.11y-2.

The util-linux.spec file changes are easy:

--- util-linux.spec.old	2003-01-14 12:32:33.000000000 -0500
+++ util-linux.spec	2003-01-22 01:54:34.000000000 -0500
@@ -10,7 +10,7 @@
 Summary: A collection of basic system utilities.
 Name: util-linux
 Version: 2.11y
-Release: 2
 License: distributable
 Group: System Environment/Base
@@ -87,6 +87,7 @@
 #Patch200: util-linux-2.11w-hammer.patch
 Patch123: util-linux-2.11y-blkgetsize-81069.patch
 Patch124: util-linux-2.11y-umount-75421.patch
+Patch125: util-linux-2.11y-cryptoapi.patch
 ########### END upstreamable
 Obsoletes: fdisk tunelp
@@ -197,6 +198,7 @@
 #patch200 -p1 -b .hammer
 %patch123 -p1 -b .blkgetsize
 %patch124 -p1 -b .umount
+%patch125 -p1 -b .cryptoapi
 # All of this patch is in except a 'max swap size' change, which
 # doesn't seem to be needed
@@ -545,6 +547,9 @@
+* Wed Jan 22 2003 James Ralston <>
+- add the CryptoAPI patch
 * Mon Jan 13 2003 Elliot Lee <> 2.11y-2
 - Fix #81069, #75421

I'll attach the patch next.

I've already made my case for this (see my 2003-01-20 00:24 comment), so I'll
shut up now.

Comment 11 James Ralston 2003-01-22 07:15:09 UTC
Created attachment 89508 [details]

Comment 12 Michael Lee Yohe 2003-01-22 16:52:27 UTC
Confirming - the patch works just as expected without a problem.  No compilation
warnings nor errors as a result of the patch.

Comment 13 Need Real Name 2003-01-24 14:44:05 UTC
Well I applied to patches to util-linux-2.11r-10 on my rh8 system; (I had to 
adjust the patch slightly on account of all the other patches) but it seems to 
work fine; though only cipher-aes came with my kernel.

Comment 14 Gerald Teschl 2003-03-15 18:09:41 UTC
I just ran into the same problem. Shipping the kenrel stuff but not the
correspondign user land tools makes absolutely no sense to me. Please
patch util-linux. Thanks.

Comment 15 Gerald Teschl 2003-06-16 17:28:25 UTC
Since there is no util-linux-2.12 in sight, please reconside rhtis for the
next release.

Comment 16 Michael Lee Yohe 2003-06-16 19:56:17 UTC
I'm still using James's patch for util-linux (losetup and mount) under Red Hat
Linux 9 without a problem.

Comment 17 Nils Philippsen 2003-07-12 13:48:41 UTC
*** Bug 88510 has been marked as a duplicate of this bug. ***

Comment 18 Nils Philippsen 2003-07-12 13:50:12 UTC
*** Bug 81574 has been marked as a duplicate of this bug. ***

Comment 19 Nils Philippsen 2003-07-12 13:54:06 UTC
The issue hasn't changed with current Rawhide stuff, what's our stance on it?

Comment 20 Elliot Lee 2003-07-14 13:12:34 UTC
Still waiting for upstream to integrate the patch.

Comment 21 Dennis Björklund 2003-08-11 12:53:14 UTC
Just for your information. The util-linux-2.12pre.tar.gz released 13 July does
not contain the patch.

Comment 22 W. Michael Petullo 2003-08-12 12:41:52 UTC
Util-linux 2.12 (the final version) does contain this crypto functionality.  
Linux kernel 2.6.0-test2 also includes support for loopback encrypted 
filesystems.  The only thin that is missing from util-linux 2.12 is the keysize 
option allowed by the old CryptoAPI patches (  At this point I am 
not sure if keysize support will be added to util-linux or not.

Again, this stuff works fine with util-linux 2.12 and the 2.6.0-test2 version 
of the Linux kernel.

Comment 23 Michael Lee Yohe 2003-08-12 14:35:35 UTC
The CryptoAPI-aware packages have been updated.

Comment 24 Michael Lee Yohe 2003-08-12 14:40:45 UTC
Wow - we can post to the bug again!  Current as of Rawhide 2.11y-25.

For those tracking this bug, I am attempting to stay current with Rawhide
util-linux package, providing binary (i386/i686) and source RPMs for
CryptoAPI-aware util-linux for Red Hat Linux 8.0 and 9.  If you wish to try them
out (I've been using them without a problem for many months with great success)
- visit:

Comment 25 Michael Lee Yohe 2003-09-12 15:18:26 UTC
You can find the -29 release (fresh from Rawhide) at:

Comment 26 Michael Lee Yohe 2003-10-20 21:14:07 UTC
Anyone have any luck getting util-linux to function well with the 2.4.22 NPTL
rawhide kernel?  Evidently, Red Hat's old patches to add CryptoAPI and
CryptoLoop to their Red Hat Linux 9 kernel were removed in favor of a 2.4.22
"accepted" CryptoAPI implementation.  Util-linux does not like the changes.

Comment 27 Gerald Teschl 2003-10-21 21:43:14 UTC
> Upstream maintainer says this will be resolved in util-linux-2.12.

util-linux-2.12 is out, but rawhide still has 2.11y. Its redhat's turn;-)

Comment 28 Need Real Name 2003-11-12 04:22:24 UTC
Fedora Core 1 has 2.11y too. :(

Comment 29 James Ralston 2003-12-03 09:21:39 UTC
Alas, you'll need more than just util-linux 2.12; you'll need to patch
the FC1 kernel as well.  :(

The kernel patch, util-linux-2.12 RPMs, and instructions are available

See also the messages I posted on 2003-12-03 to fedora-list and

Comment 30 James Ralston 2003-12-05 00:00:10 UTC
See also bug 111536.

Comment 31 W. Michael Petullo 2004-02-12 17:14:58 UTC
Fedora Core 2 Test 1 also has this bug.  Util-linux 2.12pre3 does not
contain the modern cryptoloop code.  Util-linux 2.12 is still necessary.

From the util-linux HISTORY file:

util-linux 2.12
* losetup: -p option specifies fd for passphrase
* mount: -p option specifies fd for passphrase

Version 2.12 of util-linux is available at

Comment 32 Brian G. Anderson 2004-04-05 13:43:32 UTC
Fedora rawhide now has util-linux-2.12-15.  Does this remove the need
to install our own version of util-linux?  Are the instructions for
setting up a encrypted disk the same?

Comment 33 James Ralston 2004-04-09 10:53:16 UTC
While I've had no problems with util-linux-2.12 in FC2 test2, at this
point, it's irrelevant, because the cryptoloop interface has been
deprecated in favor of dm-crypt:

The good news is that everything more-or-less works "out of the box"
in FC2 test2.  We just need cryptsetup (see bug #120487).

Comment 34 Elliot Lee 2004-04-11 20:29:11 UTC
I think I'll reopen this bug until I learn more about what the
preferred interface is and how we can best support it.

Comment 35 James Ralston 2004-04-12 09:05:13 UTC
Elliot, make sure to read this:

It sums up the situation pretty nicely.

Comment 36 Elliot Lee 2004-05-24 19:55:35 UTC
I'm going to see about getting cryptsetup into the device-mapper package.

Is there a patch to mount so that people can make use of dm-crypt from
fstab? How about easily handling rootfs on dm-crypt?

Comment 37 W. Michael Petullo 2004-05-24 20:52:15 UTC
the best way to get dm-crypt and fstab working nicely would probably
be to patch mount (or provide a mount.crypt).  This is the interface
cryptoloop used.

I proposed this idea on the dm-crypt mailing list a while back.  Look
for the thread "Would like to see mount-like interface to dm_crypt" here:

I am currently working on patching Red Hat's mkinitrd so that dm-crypt
can be used to encrypt one's root partition.  I hope to have something
working in a week or so.  Once that is done I hope to see anaconda
support for installing Red Hat/Fedora onto an encrypted root partition.

Comment 38 W. Michael Petullo 2004-05-30 02:45:52 UTC
I just submitted a patch that added encrypted root filesystem support
to mkinitrd.  See bug #124789.  I hope to see the ability to create
these filesystems added to anaconda eventually.  At this point, they
must be created by hand.

Comment 39 Elliot Lee 2004-06-03 20:22:31 UTC
At this point I'm only waiting on a patch for 'mount' - the rest is up
to others.

Comment 40 W. Michael Petullo 2004-06-17 13:15:44 UTC
Is someone actively writing a patch for mount?

Comment 41 Elliot Lee 2004-07-07 15:27:03 UTC
is out there, but it requires an unreleased version of cryptsetup, and
then it needs to be fed upstream to the util-linux maintainer. Are you
game? :)

Comment 42 Nils Philippsen 2004-07-08 10:57:14 UTC
FYI: The attachment to that article seems to be missing...

Comment 43 W. Michael Petullo 2004-07-08 14:04:43 UTC
The patch is available at:

I plan on trying it today.

Comment 44 W. Michael Petullo 2004-07-09 02:25:21 UTC
The patch mentioned in comments #42 and #43 looks promising.  I'm
trying to find more about the plans for this patch.  For the what it
is worth, the patched mount and umount need the following SELinux

# allow reading of /proc/mounts link
allow mount_t proc_t:lnk_file { read };
# manipulate /dev/mapper/control:
allow mount_t lvm_control_t:chr_file { read write ioctl };
allow mount_t device_t:chr_file { read write ioctl };
# create a device within /dev/mapper:
allow mount_t device_t:dir { write add_name remove_name };
allow mount_t device_t:blk_file { create unlink getattr read };
# allow mount to read password from parent process:
allow mount_t user_devpts_t:chr_file { read write getattr };
# allow mount to create /dev/mapper device
allow mount_t mount_t:capability { mknod };
# allow mount to look up and set proper context of new /dev/mapper device:
allow mount_t file_context_t:file { read getattr };
allow mount_t security_t:dir { search };
allow mount_t security_t:file { read write };
allow mount_t security_t:security { check_context };
allow mount_t device_t:blk_file { relabelfrom };
allow mount_t fixed_disk_device_t:blk_file { relabelto unlink };
# not sure yet why these are needed yet:
allow mount_t selinux_config_t:file { read getattr };
allow mount_t mount_t:dir { search };
allow mount_t mount_t:file { getattr read };

Comment 45 Elliot Lee 2004-08-20 16:12:50 UTC
Hi, just an update on this bug:

For the SELinux changes, please open a separate bug against
selinux-policy-targeted (and then we can change this bug to depend on
that other one).

My main problem right now is that the util-linux patch depends on an
unreleased cryptsetup package.

Comment 46 W. Michael Petullo 2004-08-20 16:18:19 UTC
Yes, I have the same problem.  I am waiting for the new cryptsetup to
be released before I give this too much attention (though I am
privately running the code on my own computer).  Unfortunately, I have
not been able to get a reply from the author concerning the future of
cryptsetup or his util-linux patch.

Comment 47 W. Michael Petullo 2005-04-18 02:29:51 UTC
Created attachment 113303 [details]
Cryptsetup patch vs. util-linux-2.12p-5

Fedora is now shipping a new fork of cryptsetup, cryptsetup-luks.  The upstream
package contains the libraries required for this patch.  Currently, the Fedora
package does not include these libraries, though.

See bug #147313, especially comment #3.

If one installs the libraries from cryptsetup-luks 1.0 that the RPM leaves out
then this patch should build.

Comment 48 Karel Zak 2005-04-18 20:18:17 UTC
The patch sent to upstream maintainer. I'm waiting for response, because I'd
rather get this integrated upstream.

Comment 49 Karel Zak 2005-08-08 13:23:49 UTC

thanks for your patch. I'm not sure with one thing. I think /proc/mount and
/etc/mtab should be almost same and we shouldn't mystify users that mounted
device is /dev/foo although the real device is /dev/mapper/foo. I think there
should not be big difference between mount by cryptsetup+mount and mount with

I think about something like:

 mount /dev/mapper/name  /mnt/dir  -o encrypt,device=/dev/sda2,key_file=foo
 umount /dev/mapper/name

 /etc/mtab:   /dev/mapper/name on /mnt/dir type ext3 (rw,encrypt,device=/dev/sda2)

 /etc/fstab:  /dev/mapper/name  /mnt/dir etx3   encrypt,device=/dev/sda2

but I have to check the others distributions how they resolve it.

Comment 50 W. Michael Petullo 2005-08-09 17:16:34 UTC
Sounds fine.  By the way, I did not write the patch.  The author is Christophe 

Comment 51 Karel Zak 2005-08-26 10:20:44 UTC
Patch & FC5 src.rpm:

Comment 52 Karel Zak 2006-02-07 09:29:00 UTC
*** Bug 179866 has been marked as a duplicate of this bug. ***

Comment 53 Levente Farkas 2006-03-30 09:43:51 UTC
any news on fc5?

Comment 54 W. Michael Petullo 2006-08-26 20:45:41 UTC
This bug is quite old.  Much has happened since I opened it.  The value of
patching util-linux may be less now then it was then.

In light of, the fact that I can plug in a removable, encrypted drive and GNOME
will automatically prompt me for a password and mount it[1], I am really no
longer interested in mount itself being patched.  Also, encrypted swap[2] has
been provided without this patch.  Furthermore, on the command line, the
cryptsetup, mount sequence is easy to use and I think people are getting used to
it.  Moving the dm-crypt code to mount probably does not have much value.

I may be overlooking some use case here, but my opinion after several years is
that util-linux need not be patched.  I am going to close this: WONTFIX.


Note You need to log in before you can comment on or make changes to this bug.