| Summary: | sys-apps/util-linux 2.12q-r3 losetup and mount requires long password, breaks legacy volumes | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Robert J. Brown <rj> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED INVALID | ||
| Severity: | blocker | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://forums.gentoo.org/viewtopic-p-2763559.html?sid=f597b8bf8ee4d500335d98aa6b77ee99#2763559 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Robert J. Brown
2005-09-30 00:34:30 UTC
were these volumes created with util-linux 2.12i-r1 ? 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. re-emerge util-linux with USE=old-crypt and use `losetup-old-crypt` and `mount-old-crypt` 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 documented? 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. 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?
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 encryption. 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 a *BAD IDEA*! 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. This problem is not solved. The person who tagged it as resolved was operating under a misconception. 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 following: # 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. All references above to AES-256 should read AES or AES-128 or AES_i586. Sorry for the confusion. As stated above, but just in case you missed it, the problem was introduced somewhere between mount-2.12i and mount-2.12q Mainline util-linux compatible mount options for /etc/fstab
encryption=twofish256,phash=unhashed2
Mainline util-linux compatible losetup command options
losetup -e twofish256 -H unhashed2 ......
kerneli.org compatible mount options for /etc/fstab
encryption=twofish256,phash=rmd160
kerneli.org 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.
Not so, at least on my system:[code]ezekiel ~ # encryption=aes,phash=unhashed2 ezekiel ~ # mount /crypto_dvd Password: Error: Password must be at least 20 characters. ezekiel ~ # [/code] 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)
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
Password:
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
Password:
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
Password:
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.
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/ Password: ezekiel ~ # df Filesystem 1K-blocks Used Available Use% Mounted on (...etc...) /dev/cdrom 1693312 1693312 0 100% /crypto_dvd All with the same exact dvd in the drive. 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 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. 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 The old-crypt versions do not work for this. See post #4 above... 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) * * * 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...)
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 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. |
