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   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact:
Keywords: FutureFeature
: 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:
Story Points: ---
Clone Of:
Last Closed: 2006-08-26 20:45:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
util-linux-2.11y-cryptoapi.patch (63.62 KB, patch)
2003-01-22 07:15 UTC, James Ralston
no flags Details | Diff
Cryptsetup patch vs. util-linux-2.12p-5 (14.99 KB, patch)
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
(http://www.kernel.org/pub/linux/kernel/crypto/v2.4/) 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
+Release: 2.int
 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 <ralston@pobox.com> 2.11y-2.int
+- add the CryptoAPI patch
 * Mon Jan 13 2003 Elliot Lee <sopwith@redhat.com> 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 (kerneli.org).  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.

[1] https://www.redhat.com/magazine/012oct05/features/hal/
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127378

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