Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 108771 - short passphrase fix for losetup under 2.6.12-gentoo-r10 fails under to 2.6.13-gentoo-r3
Summary: short passphrase fix for losetup under 2.6.12-gentoo-r10 fails under to 2.6.1...
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL: http://forums.gentoo.org/viewtopic-p-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-10 13:35 UTC by Robert J. Brown
Modified: 2006-01-10 08:16 UTC (History)
2 users (show)

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


Attachments
Mount.strace as requested (mount.strace,6.00 KB, text/plain)
2005-12-13 11:47 UTC, Jason Keirstead
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert J. Brown 2005-10-10 13:35:39 UTC
This is a continuation of the symptoms reported with bug 107680.

That problem was worked around by some additional mount options in /etc/fstab
under under 2.6.12-gentoo-r10, but this fails to work under to 2.6.13-gentoo-r3.

The filesystem can still be mounted under under 2.6.12-gentoo-r10, even though
util-linux was upgraded to 2.12r from util-linux-2.12q, so the thing that
changed must have been in the kernel.

Reproducible: Always
Steps to Reproduce:
1.  See bug 107680, only use 2.6.13-gentoo-r3 instead of 2.6.12-gentoo-r10.

Actual Results:  
See bug 107680, only use 2.6.13-gentoo-r3 instead of 2.6.12-gentoo-r10.

Expected Results:  
The encrypted reiserfs filesystem should have mounted the same way it does under
2.6.12-gentoo-r10
Comment 1 Daniel Drake (RETIRED) gentoo-dev 2005-11-01 07:11:33 UTC
So what exactly is the error you are getting when trying to mount? Can you
attach your current fstab for clarification?
Comment 2 Robert J. Brown 2005-11-01 09:17:16 UTC
ezekiel ~ # uname -a
Linux ezekiel.elilabs.com 2.6.12-gentoo-r10 #1 Thu Sep 29 16:04:42 EDT 2005 i686
AMD Athlon(tm)  AuthenticAMD GNU/Linux

The relevant lines from /etc/fstab are:
/dev/md0                /crypto_raid    reiserfs       
noauto,encryption=AES256,phash=unhashed2        0 0

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

Please see bug 107680 for further details.  The symptoms are the same that I was
experiencing there before changing the /etc/fstab entries to those shown above.
Comment 3 Daniel Drake (RETIRED) gentoo-dev 2005-11-01 10:16:54 UTC
I've glanced over the bug but am still unclear on this:

So what exactly is the error you are getting when trying to mount?
Comment 4 Robert J. Brown 2005-11-01 10:52:25 UTC
As it is the start of a new month, and the machine in question is my backup
server, it will be busy making archival backups for another day or so;
therefore, I cannot reb oot it to get it running 2.6.13-r3.  It is presently
running 2.6.12-r10 as a workaraound for this problem.  As soon as I can reboot
into 2.6.13-r3, I will provide exact copy of the error message, but basicly, it
says I need a longer password, and fails to mount the drive because it decrypts
it incorrectly.
Comment 5 Daniel Drake (RETIRED) gentoo-dev 2005-11-24 16:56:45 UTC
Please reopen when you provide more info
Comment 6 Robert J. Brown 2005-11-24 19:22:30 UTC
OK, I just booted the system into 2.6.13-gentoo-r3:
[code]ezekiel ~ # uname -a
Linux ezekiel.elilabs.com 2.6.13-gentoo-r3 #2 Mon Oct 10 15:09:26 EDT 2005 i686
AMD Athlon(tm)  AuthenticAMD GNU/Linux[/code]
Now to try to mount an aes256 encrypted filesystem.  First, here is the relevant
entry in [color=green]/etc/fstab[/color]:[code]/dev/md0               
/crypto_raid    reiserfs        noauto,encryption=AES256,phash=unhashed2       
0 0[/code]
Now we attampt to mount with an 8 char password, which we [u]must[/u] use, since
that is the wat the filesystem was created long ago:[code]ezekiel ~ # mount
/crypto_raid/
Password: 
WARNING - Please use longer password (20 or more characters)
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

ezekiel ~ # [/code]
So it fails the mount, yet if I boot back into 2.6.12-gentoo-r10:[code]ezekiel ~
# uname -a
Linux ezekiel.elilabs.com 2.6.12-gentoo-r10 #1 Thu Sep 29 16:04:42 EDT 2005 i686
AMD Athlon(tm)  AuthenticAMD GNU/Linux[/code]
And try to mount the same fiolesystem, using the same
[color=green]/etc/fstab[/color]:[code}ezekiel ~ # mount /crypto_raid/
Password: 
WARNING - Please use longer password (20 or more characters)
ezekiel ~ # [/code]
And the filesystem mounts just fine, but with a warning that still would only
make sense if one were creating a new filesystem; after all, one does not have
the option to mount an already  existing filesystem with a different password
just because the requirements were changed after the original filesystem was
created.

It needs to be stresses that although the above example was using a RAID-1 on
hard disk drives, there are also literraly hundreds of archival backup dvds
encrypted the samew waay -- with an 8 char password --  so the option of
converting everything over to longer passwords is really out of the question.

What is needed is a way to mount these filesystems -- especially the dvds --
using a short password, otherwise I will have to keep a system around running
2.6.12 for 5 more years just to insure the ability to read the archival dvds.

Is there some reason why we cannot just have a command line option to mount or
losetup that will override the long password requirement?  That really should
not be too hard to do.
Comment 7 Robert J. Brown 2005-11-24 19:23:53 UTC
Oops!  Sorry about the phpbb [code] and [color] tags.  
I forgot I was in bugzilla.  :-(
Comment 8 Daniel Drake (RETIRED) gentoo-dev 2005-12-02 09:39:01 UTC
If you are bothered by the warning then you should file a separate bug for that.

When you tried to mount it under 2.6.13, it said:

mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so



Did you try that? Can we see the results? (Ideally the whole of dmesg as an
attachment, *after* you have tried to mount).

It would also be a good idea to reproduce this on the latest development kernel
(currently vanilla-sources-2.6.15_rc4)
Comment 9 Robert J. Brown 2005-12-02 09:46:10 UTC
Listen carefully!  This is a very simple problem caused by what someone thought
was a good idea.  Newer kernels and the newer mount program are now enforcing
the "good idea": make the user enter a long (20 char) password.  This is great
for creating a new filesystem, but it absolutely is totally moronic for a
pre-existing filesystem.  One does not have the option of entering a 20 char
password for a filesystem that was created long ago with a shorter password.  

All that is needed is an option, such as --short-password or some such thing, to
mount, to allow the user to proceed without forcing him to enter a long password.

Why is everybody having such a hard time understanding this?
Comment 10 Daniel Drake (RETIRED) gentoo-dev 2005-12-02 10:01:18 UTC
That would be a valid explanation, but are you sure?

The message you posted says:
> WARNING - Please use longer password (20 or more characters)

That doesn't sound like an actual error, for the reason that it says it's a
WARNING, and also the reason it is phrased like a suggestion rather than a
requirement. You also saw this message on previous kernels (right?) so it's not
like its something new.


Am I missing something? Maybe you are basing your conclusion on something else
that I'm not seeing...
Comment 11 Robert J. Brown 2005-12-02 10:54:08 UTC
If you will look at bug 107680, which is referenced in the original post here,
you will see that previously, the change was made to mount that required the
user to enter a 20 char passphrase, but if I used an earlier version of mount,
it would take my short password and go ahead and mount the filesystem.  With
some help from a thread I started on gentoo forums, I was able to add some
options to the entry in /etc/fstab for the filesystem so that it would work with
the newer version of mount.

Then a kernel update came along, and even with the older version of mount, or
with the options that worked before with the newer version of mount, it still
refused to accept my short password, and therefor failed to mount the filesystem.

So to sum it up, the problem was first caused by a newer version of mount (and
losetup), and then when the newer kernel was installed, it failed even with the
old version of mount.  

So I am now still running with the old kernel and the new version of mount and
the aforementioned options in my /etc/fstab, but I fear that I will have to make
a special livecd with a big ram disk so I can boot from the live cd and then
have it copy the squashfs to the big ram disk, so that I can put an encrypted
backup dvd into the cd/dvd drive and read it; otherwise, I will not be able to
keep the system anywhere near up to date and still be able to read my backup dvds.

I am planning to switch to the longer password at the end of the year, but I
will still need to be able to read those older encrypted dvds that still have
the short password.  Newer backup dvds will use the long password, as will the
online raid-1 mirror.

It is still hard for me to believe that I am the only person who has encountered
a problem with this.  Am I the only person who actually encrypts my backups?
Comment 12 Daniel Drake (RETIRED) gentoo-dev 2005-12-02 11:36:31 UTC
Ok, but you are jumping to conclusions. I'm not convinced that the new kernel is
imposing a 20 character minimum length or has dropped that parameter. Of course,
you might be totally correct, but I don't see any true information here which
confirms that. If you want my help, you have to convince me of this :)

So, please get the dmesg output I asked for in comment #8.
Comment 13 Robert J. Brown 2005-12-02 13:13:08 UTC
OK, but it will be a few days before I can get the dmesg output, as the system
is busy doing monthly archival backups right now.  Hopefully Monday or Tuesday I
will post the output you requested.  Remember, I have to reboot into the newer
kernel to do this.  Sorry about the delay.
Comment 14 Daniel Drake (RETIRED) gentoo-dev 2005-12-08 04:29:40 UTC
When you test this, it would also be useful to see the output of a straced mount
attempt,
i.e.: # strace -f -o mount.strace mount /crypto_raid/

Then upload the 'mount.strace' output file here.
Comment 15 Daniel Drake (RETIRED) gentoo-dev 2005-12-08 04:41:54 UTC
Some other things to try and useful info to check:

Is util-linux compiled with USE=crypt?

Which version of loop-aes is installed?
Have you rebuilt it since you upgraded kernel? (this is necessary because
loop-aes is a kernel module)
You can check this by posting the output of "equery files loop-aes" (equery is
in the gentoolkit package0

Output of this would be interesting: grep LOOP /usr/src/linux/.config


This is looking less an less like a kernel problem. The encryption= and phash=
options are not sent to the kernel at all. They are handled by util-linux. Also,
the block driver used to mount this is loop-aes, which is not part of the
kernel, it is an external package.
Comment 16 Jason Keirstead 2005-12-13 11:27:36 UTC
I havethis problem as well Robert. Only it is even worse, as I have a whole 
volume of work-related source code (6 GB worth) in an encrypted volume that as 
of this morning I am totally unable to access. I have been trying *everything* 
I can think of, rolling back util-linux, rolling back the kernel, using every 
phash method I can come across, all with no success, because near as I can tell 
the encryption must rely on some specific version of the kernel/util-linux and 
some specific phash to actually work. 
 
All in all I have wasted the past 6 hours on this, before I even found this bug 
report - there does not seem to be much help for this problem anywhere, even 
though I have found it reported in several places I have seen few solutions, 
other than rebooting off an old OS to extract the data. I will now try booting 
off a 2004 live CD to see if I can access the data that way (been downloading 
now for the past hour, such an old ISO is only available on slow mirrors now). 
 
Personally, I can not believe that someone would change such a core thing as 
the loopback encryption method without either leaving in a compatibility layer 
that auto-detects the old encryption type and uses the old method, or else 
prints a HUGE WARNING to the screen when you go to upgrade something that can 
cause you to lose access to all your data. 
 
I have been extremely frustrated with this whole situation, so much so that 
once I get this volume decrypted I am **never** using linux loopback encryption 
again, I am going to either use some third-party application level encryption, 
or roll my own, or purchase a commercial application. I can't afford to waste 
8+ hours of my day over this again. 
 
Comment 17 Daniel Drake (RETIRED) gentoo-dev 2005-12-13 11:38:06 UTC
I'm sorry that this problem has caused you trouble. Please remember that the
loop encryption is *not* part of the kernel, and neither is there any evidence
saying that the old encryption methods have been dropped (I even had a quick
look at the source myself).

I will help troubleshoot the problem if you can provide me with the information
I have requested in comment #8, comment #14 and comment #15. It would also be
useful if you could clarify the rest of the situation since you didn't include
many details. Even if you are repeating what Robert has said already, please
provide a detailed report.
Comment 18 Robert J. Brown 2005-12-13 11:42:34 UTC
Well, at least I am not the only person to have been hit by this, not that I
would wish it on anyone, but at least its existence has been independently
verified by someone else.

Yes, booting off that 2004 live CD will work.  You will then have to copy the
file to some other volume, and either leave it as plain text, or encrypt in with
the new algorith, or use some other encryption method.

I am using loopback aes256 encryption for my network backup server.  It keeps
the backups on a 3-way RAID-1 mirror, and archives to encrypted compressed dvds.
 I can live with converting the mirror to a new encryption method, although it
will be a pain, but there is *NO WAY* I am going to copy and re-encrypt hundreds
of archival dvds!

Your filesystem size of 6 GB is trivial compared to what I am dealing with.  Can
you say several hundred dvds with about 8 GB of compressed encrypted data on
each one?  That comes to around 1.6 TB!

I have to use either cryptoloop, or the loopback encryption, or dm.crypt, as I
need a fully functional reiserfs as an encrypted filesystem on the raid.  I
guess I could switch to some other method for the archival dvds, but I really do
not want to have to do that.

All we need is a backward compatibility option for losetup to use the old way.
Comment 19 Jason Keirstead 2005-12-13 11:44:57 UTC
Ok - to expand on my previous rant a bit, let me post the actual problem. 
 
I have an AES encrypted volume I made earlier this year, probably around May or 
so. I made, and have always mounted, said volume like this: 
 
losetup -e aes /dev/loop0 ~/secure.crypt 
<Enter a 16 char password> 
mount -t reiserfs -o loop ~/secure.crypt ~/secure 
 
Now, starting sometime this month, after an emerge sync, I am unable to mount 
the data. First, it no longer accepts my 16 char password, saying it has to be 
20 chars. So, I rebuild util-linux with a lower limit 
(-DLOOP_PASSWORD_MIN_LENGTH=8), and losetup now accepts my password, but the 
filesystem is not recognized when I try to mount. 
 
I have tried every -H <phash> method available in losetup, none of them work. 
 
Now, to be even more confusing, I cannot figure out what the difference is 
between 'emerge loop-aes' and enabling loopback encryption in the kernel 
itself. I do not know which I had enabled when I created this volume. How can I 
tell?  
 
I am really desperate for help on this issue. 
 
Comment 20 Jason Keirstead 2005-12-13 11:47:34 UTC
Created attachment 74657 [details]
Mount.strace as requested

Password replaced with XXXXXXXXXXXXXXXX
Comment 21 Robert J. Brown 2005-12-13 11:56:51 UTC
Thanks, Jason.  My backup server is currently busy and cannot be rebooted for a
few more days.  (Mashing around with HUGE amounts of data takes time...)  I was
going to provide such an strace whenI could do a reboot.  Hopefully, your strace
will suffice for the investigation.  :-)
Comment 22 Jason Keirstead 2005-12-13 13:53:19 UTC
Alas - I am unable to even access the data booting off of the 2004 live CD.

I am convinced I must have had some wierd combination of utlin-linux and
CryptoAPI going on.

I have also tried copying the encrypted volumne to a debian sid machine, and
could not decrypt it there either, using any of the supplied phash algos.
Comment 23 Robert J. Brown 2005-12-13 15:17:17 UTC
If you cannot read it with that old live cd, then I fear you have a different
problem that I have.  Perhaps I should go ahead and make the strace when I can
reboot the backup server -- probably not before next Monday at this rate.
Comment 24 Daniel Drake (RETIRED) gentoo-dev 2005-12-13 16:08:27 UTC
I also need the other info I asked about, see comment #8 and comment #15
Comment 25 Robert J. Brown 2005-12-13 16:24:24 UTC
I will try to get all that info to yu when I can reboot the server to the newer
kernel.  Right now, it is performing its assigned duties with an older kernel,
as the newer one has this mount problem...
Comment 26 Daniel Drake (RETIRED) gentoo-dev 2005-12-29 12:08:24 UTC
There is also an "old-crypt" flag for util-linux which may be worth trying, especially in Jason's case. You'll then get "mount-old-crypt" and "losetup-old-crypt" which can be used instead of "mount" and "losetup" respectively.
Comment 27 Daniel Drake (RETIRED) gentoo-dev 2006-01-10 08:16:28 UTC
Please reopen when requested info arrives.