Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 107680 - sys-apps/util-linux 2.12q-r3 losetup and mount requires long password, breaks legacy volumes
Summary: sys-apps/util-linux 2.12q-r3 losetup and mount requires long password, breaks...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High blocker (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Reported: 2005-09-30 00:34 UTC by Robert J. Brown
Modified: 2005-10-11 11:10 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Robert J. Brown 2005-09-30 00:34:30 UTC
Upgrading to the losetup and mount commands found in sys-apps/util-linux version
2.12q-r3 breaks legacy volumes because the new commands require a 20+ char
password, and legacy volumes could have been made with a shorter password. 
These volumes cannot be accessed with the new commands.

Understanding the good intentions of the 20+ character requirement, what is
needed is an option to override it for legacy volumes that were made with
shorter passwords.  The option might even issue a warning, but if so, then that
warning must be squelched by the -q option so that scripts will not break
because they saw the warning.

I presently have nearly a terrabyte of raid that is unmountable, and hundreds of
archival dvds that are likewise unmountable -- all because they used a password
shorter than 20 characters in their creation.  :-(

I imagine others are going to discover they are in a similar predicament.  ;-(

Reproducible: Always
Steps to Reproduce:
1.  Using an earlier version of losetup, create an encrypted filesystem using a
password shorter than 20 characters.  I used AES-256, but any method ought to
show the problem.

2. Attempt to mount that filesystem on a newer system that uses the new mount
and losetup commands from sys-apps/util-linux 2.12q-r3.

3. Observe that it is impossible to mount because the new system will not let
you enter the short password that you used to create the filesystem.

Actual Results:  
The file system could not be mounted.  (Also, I filed the Bug report.)

Expected Results:  
The new losetup and mount commands should have a command line option to override
the requirement for a password greater than 20 characters long.

This problem renders the raid array on my backup server unmountable, as well as
rendering all my archival backup dvds unmountable.  For me, at least, this is
mission critical, as not only can I no longer access any backups at all, but
also I cannot make any new backups unless I replace all the drives in the raid
array and mount a new filesystem there with a long password.
Comment 1 SpanKY gentoo-dev 2005-09-30 05:56:06 UTC
were these volumes created with util-linux 2.12i-r1 ?
Comment 2 Robert J. Brown 2005-09-30 10:39:34 UTC
I am not sure what version they were created with, but it was an earlier version
that did not require a certain password length.  The volumes in question are a
3-way raid mirror and a whole boat load of dvds.  The most recent dvds were
created with a version that was not over 2 months old, but the raid volumes were
initially created a year ago, and have been mounted many times since then.  Up
until I did this most recent "emerge --update world" everything was working great. 

I guess I could try booting the box with a livecd and try to mount one of the
raid mirror's drives that way.  Then I could look at my backups from a week or
so ago and see what version I was using just prior to the problem.
Comment 3 SpanKY gentoo-dev 2005-09-30 10:56:06 UTC
re-emerge util-linux with USE=old-crypt and use `losetup-old-crypt` and
Comment 4 Robert J. Brown 2005-09-30 16:09:02 UTC
OK, so I emerged as specified, and I now have the losetup-old-crypt and
mount-old-crypt executables, but when I try to run the mount-old-crypt command,
I get:

ezekiel ~ # mount-old-crypt /crypto_raid/
You must specify a key size (in bits) for use with CryptoAPI encryption.

So I did a mount-old-crypt -h but found nothng about how to set the key size;
neither is there any man page for either mount-old-crypt or losetup-old-crypt. 
The thing never asked for a password or anything; it just barfed.

So *HOW* does one use these *-old-crypt commands?  And how/where are they

I still think an override option to the mount and losetup commands would be a
nicer fix, but this approach will do for now -- if I can make it work.
Comment 5 Robert J. Brown 2005-09-30 16:11:45 UTC
I think it wants the information that it should be able to find in my /etc/fstab:

# our RAID-1 can be use encrypted or not, only one way at a time, mount manually
/dev/md0                /raid           reiserfs        noauto                 
        0 0
/dev/md0                /crypto_raid    reiserfs        noauto,encryption=aes  
        0 0

Why doesn't this work?
Comment 6 Robert J. Brown 2005-09-30 19:11:12 UTC
I have search around a bit more, and the old-crypt thing is "barking up the
wrong tree".  I never did use the old crypto-api; I always used loop-aes for my

The latest emerge system/world has gotten me a pedantic version of mount that
insists that I use a 20+ character password, just because it is a "good idea" --
kind of like passwd insisting on a minimum length password for a login account;
it ought to be over-ridable, at least certainly by root!  If I already have an
encrypted filesystem that was made using a shorter password, this "good idea"
makes my already existing filesystem unusable.  The "good idea" turns out to be

I guess I will have to learn how to fetch the sources for a package and debug
this myself, because it appears that my bug report was totally misunderstood.  

I do not need ancient encryption support; I just need to be able to specify a
password shorter than 20 characters for a loop-aes encrypted filesystem that was
created with such a shorter password.  

The new mount and losetup commands have added a pedantic check on the length of
the password that refuses to operate unless the password is at least 20
characters long.  I *CAN'T* mount my already existing filesystem with a 20
character password, because it was not created with a 20 character password.

And I most certainly cannot throw it away and make a nice shiny brand new empty
umpty-hundred gigabyte filesystem to take its place, because I have no way to
put the data inot it that is in the old and now unmountable filesystem. 
Furthermore, I have no intention of remaking hundreds of encrypted backup dvds
just because somebody thinks I ought to use a longer password.
Comment 7 Robert J. Brown 2005-09-30 19:13:17 UTC
This problem is not solved.  The person who tagged it as resolved was operating
under a misconception.
Comment 8 Robert J. Brown 2005-09-30 20:33:31 UTC
Onthe system that is my backup server (where this problem was manifested), I
just mounted the gentoo universal install livecd 2004.2 from 20-Oct-2004
manually as /cdrom, and then mounted /cdrom/livecd.squashfs as /sq thru a loop
device to handle the squashed filesystem.  I then tried the /sq/sbin/losetup and
/sq/bin/mount commands from that livecd.  It worked flawlessly.  I did the

  # mount /dev/cdrom /cdrom
  # mount /cdrom/livecd.squashfs /sq
  # /sq/sbin/losetup -e aes /dev/loop2 /dev/hda5

This asked me fora password, to which I entered my short password, and the
command succeded without a complaint.  Getting braver, I tried to mount the
encrypted raid mirror:

  # /sq/bin/mount /crypto_raid

This too asked for a password, to which I entered my short password.  The
command returned to a prompt without complaint.  I did a df and say my raid
mirror mounted as /crypto_raid:

  # df
  Filesystem           1K-blocks      Used Available Use% Mounted on
  /dev/hda3             48836072   5979028  42857044  13% /
  udev                    452116       228    451888   1% /dev
  /dev/hda6            187464736     32840 187431896   1% /dvds
  none                    452116         0    452116   0% /dev/shm
  /dev/md0             239256564 161819504  77437060  68% /crypto_raid

Now I wanted to be sure I could actually read a directory:

  # ls -la /crypto_raid/
  total 1
  drwxr-xr-x   8 root root 176 Aug  1 17:59 .
  drwxr-xr-x  25 root root 808 Sep 30 23:04 ..
  drwxr-xr-x  16 root root 384 Sep 16 12:37 backups
  drwxr-xr-x   2 root root  48 Sep 28 08:00 dvds
  drwxr-xr-x   2 root root 568 Sep 28 20:53 log
  drwxr-xr-x  16 root root 384 Sep 16 12:38 snapshots
  drwxr-xr-x  16 root root 384 Sep 16 12:39 tmp

Now to determine the version of the mount that I was using before the most
recent emerge system/world:

  # cd /crypto_raid/snapshots/ezekiel/2005/09/04/22.54.52/bin

This puts me in the /bin directory of the backup server on September 4, 2005;
this was before the problem occurred.  Now to get mount to tell us its version:

  # ./mount -V
  mount: mount-2.12i

TA DA!  Now back to the current setup:

  # cd /root
  # mount -V
  mount: mount-2.12q

So the problem was introduced somewhere between mount-2.12i and mount-2.12q !!!

Could we please make a change in mount (that will persist for many years) that
will allow the old behavior of the short password if the command line specifies
an option, such as "--shortpw", or some such thing?  

This is essential in order for people to be able to mount filesystems that were
created before the change to the 20+ character password.  I, for one, use such
filesystems for my backup server raid mirror (which holds about 2 or 3 months
worth of backups), and for my archival dvds, which are encrypted.  These dvds
need to be readable for at least 5 years.

I hope I have more fully clarified what the actual problem is now.
Comment 9 Robert J. Brown 2005-09-30 23:55:29 UTC
All references above to AES-256 should read AES or AES-128 or AES_i586.

Sorry for the confusion. 
Comment 10 Robert J. Brown 2005-10-01 11:46:56 UTC
As stated above, but just in case you missed it, the problem was introduced
somewhere between mount-2.12i and mount-2.12q 
Comment 11 anonymous 2005-10-03 22:10:50 UTC
Mainline util-linux compatible mount options for /etc/fstab


Mainline util-linux compatible losetup command options
    losetup -e twofish256 -H unhashed2 ...... compatible mount options for /etc/fstab

    encryption=twofish256,phash=rmd160 compatible losetup command options

    losetup -e twofish256 -H rmd160 ......

mount and losetup programs don't enforce 20 character minimum passphrase
length when using 'rmd160' or 'unhashed2' hash functions.
Comment 12 Robert J. Brown 2005-10-03 22:27:06 UTC
Not so, at least on my system:[code]ezekiel ~ # encryption=aes,phash=unhashed2
ezekiel ~ # mount /crypto_dvd
Error: Password must be at least 20 characters.
ezekiel ~ # [/code]
Comment 13 anonymous 2005-10-04 16:08:44 UTC
They are mount options, not environmental variables.

# grep /cryptcd /etc/fstab
/dev/cdrom /cryptcd iso9660 
defaults,noauto,ro,user,loop=/dev/loop1,encryption=twofish256,phash=unhashed2 0 0
(Above is supposed to be one long line. Damn forced line breaks)
Comment 14 Robert J. Brown 2005-10-04 17:54:40 UTC
Well now, isn't that wonderful?  But that only works if the disk was created
using that same hashing algorithm, doesn't it?  

Here is what my old /etc/fstab entry used to look like when I made the dvd:

/dev/cdrom		/crypto_dvd	squashfs \ 
noauto,ro,encryption=aes		0 0

(note use of backslash as line continuation is for posting only)

And thios is what I get now when I try to mount with this:

ezekiel ~ # mount /crypto_dvd
Error: Password must be at least 20 characters.

And here is how I modified that line to try to mount it now:

/dev/cdrom		/crypto_dvd	squashfs \
noauto,ro,encryption=aes,phash=unhashed2	0 0

And this is what I get when I try to use that to mount a dvd created with the
old setup:

ezekiel ~ # mount /crypto_dvd
WARNING - Please use longer password (20 or more characters)
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

So it looks like it stopped bellyaching about the short password, but the volume
will not mount because the hasing algorithm is different from what I used to
create the dvd.

Ditto for the other hash:

/dev/cdrom		/crypto_dvd	squashfs \
noauto,ro,encryption=aes,phash=rmd160	0 0

This gets me:

ezekiel ~ # mount /crypto_dvd
WARNING - Please use longer password (20 or more characters)
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

So your workaround only works if you created the disk the same way, which I did
not, seeing as how the dvd was burned over a year ago!

However, I copied an old version of losetup and mount from an old system over,
and I can mount both the dvd and the raid just fine with that, as I mentioned in
an earlier post.

The "mount" and "losetup" commands need to be fixed to permit a short password.
Comment 15 Robert J. Brown 2005-10-04 17:59:09 UTC
BTW Using the old mount, which I renamed to not colide with the new one, and
reverting back to the original line in /etc/fstab, I get this:

/dev/cdrom		/crypto_dvd	squashfs \
noauto,ro,encryption=aes	0 0

ezekiel ~ # mount_shortpw /crypto_dvd/
ezekiel ~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cdrom             1693312   1693312         0 100% /crypto_dvd

All with the same exact dvd in the drive.
Comment 16 SpanKY gentoo-dev 2005-10-04 18:04:07 UTC
why dont you downgrade to util-linux-2.12q and see if it works

if it doesnt, downgrade to util-linux-2.12i and see if that works
Comment 17 Robert J. Brown 2005-10-04 18:13:36 UTC
I already know that 2.12i works, as that is where my mount_shortpw came from.

But depending on an old version of mount to continue to work with new version of
the kernel et al for the next 5 years or more is foolhardy.  The mount and
losetup commands need to be able to support volumes that were written before
this pedantic 20 char limit was arbitrarily imposed.
Comment 18 SpanKY gentoo-dev 2005-10-04 18:18:34 UTC
if 2.12i works then that means you have to use `mount-old-crypt` and
`losetup-old-crypt` in order to mount your volumes, like i said earlier

`mount` and `losetup` from util-linux-2.12q+ will not be able to mount the
volumes you created with util-linux-2.12i
Comment 19 Robert J. Brown 2005-10-04 18:23:26 UTC
The old-crypt versions do not work for this.  See post #4 above...
Comment 20 anonymous 2005-10-04 22:22:04 UTC
Robert J. Brown's old /etc/fstab line:

/dev/cdrom      /crypto_dvd squashfs \
  noauto,ro,encryption=aes        0 0 

New /etc/fstab line:                  

/dev/cdrom      /crypto_dvd squashfs \
  noauto,ro,encryption=AES256,phash=unhashed2  0  0

(backslash as line continuation is for posting only)
Comment 21 Robert J. Brown 2005-10-04 22:35:43 UTC
* * *  T H A N K S  ! ! !  * * *

That worked !!!  :-)

Now, perhaps we can close this bug and start a request for a bit more
explanation in the losetup man page about these options; all it says is:

       -H phash
              Uses phash function to hash password. Available  hash  functions
              are  sha256, sha384, sha512 and rmd160. unhashed1, unhashed2 and
              unhashed3 functions also exist for compatibility with some obso-
              lete implementations.

It might be nice to explain these a bit more fully.  :-\

Thanks again, bug closed, resolution INVALID.

PS Sorry it was so hard for me to GET IT.  :-(
   (I still thinks the man page could have been a lot clearer...)
Comment 22 Mina Naguib 2005-10-11 08:41:57 UTC
Quick fix re-cap for all new people running into this:

1. If using `losetup`, add this commandline option "-H unhashed2"
2. If using fstab, add "phash=unhashed2" to the parameters portion
Comment 23 Robert J. Brown 2005-10-11 11:10:14 UTC
While the above quick fix worked for 2.6.12-r10, it fails to work with
2.6.13-r3.  I have opened up bug 108771 to deal with this, since the change
seems to be in the kernel this time, wereas before it was in util-linux.