mount password under 2.6.2.6.12-gentoo-r10

Moriah

I just upgraded the kernel of my backup server from 2.6.12-gentoo-r6 to 2.6.12-gentoo-r10. I have a large raid 3-way mirror that is using aes-256 encryption. Previously, I mounted it with the mount command, which requested a password. I entered a password that I find useful. It is 8 characters long. Now, under 2.6.12-gentoo-r10, mount refuses to accept any password shorter than 20 characters. This renders my raid 3-way mirror full of backups absolutely useless! It also no doubt renders my 1 1/2 years worth of compressed encrypted archival dvd backups useless as well. :cry:

Without ranting about what kind of moron would suddenly make such a change to the mount command, I instantly checked the man page for mount to see what override option they provided for legacy compatibility. NONE !!!

Yikes! So now what do I do? How do I mount my raid 3-way mirror that was protected by an 8 character password previously?

steveb · Advocate Joined: 18 Sep 2002 Posts: 4564

downgrade the kernel back to 2.6.12-gentoo-r6 and downgrade anything else to the level where you could mount with 8 characters. boot up the system and then mount the partition with the 8 characters password and change the password to more then 20 chars. then reupdate the kernel and the other stuff back to the new version.

Moriah · Posted: Thu Sep 29, 2005 11:14 pm Post subject:

That doesn't even make sense to me. It would seem that I would have to mount the filesystem under r6 with the 8 char pw and copy it to another filesystem mounted under r10 with a 20+ char pw. While that is possible, it requires 2 large filesystems. Furthermore, I have literraly hundreds of compressed encrypted archival dvds that I would likewise have to copy. This is much more than unreasonable; it is absurd!

What is needed is an option to mount that will allow one to deliberately override the 20 char minimum on the password. I cannot believe I am the only person whose stuff has been broken by this. As root, I should be able to override the *RECOMMENDED* password length, just as I can with a login password. A suitable warning message might be a nice idea, but allow the -q switch to prevent it from showing, so as to not break its use inside scripts, etc.

Moriah · Posted: Thu Sep 29, 2005 11:45 pm Post subject: worse than I thought

The situation is actually much worse than I thought it was. Earlier today I did an emerge --sync followed by the usual emerge --update system and emerge --update world to bring the backup server up to date. The encrypted filesystem was already mounted before this started, and remained so until I rebooted after the kernel build to upgrade from r6 to r10.

It turns out that it is not a kernel problem, but rather something in the upgrade that forces the 20 char password. I tried a losetup and it too forces the 20 char password, so I think it is either in losetup, or in the aes256 encryption stuff, but I though the aes256 encryption stuff was a kernel module, which I made compiled into the kernel, so it can't be there. It must be in losetup somewhere.

Indeed, observe:

Moriah · Posted: Fri Sep 30, 2005 3:40 am Post subject: its both mount and losetup

Moriah · Posted: Sun Oct 02, 2005 9:16 pm Post subject: bug report filed

Bugzilla Bug 107680 has been filed on this issue. See https://bugs.gentoo.org/show_bug.cgi?id=107680 for details.

Moriah · Posted: Mon Oct 10, 2005 8:27 pm Post subject: like a recurrent nightmare

This problem is getting like a recurrent nightmare!

The bugzilla bug report finally resulted in a workaround that required changes to /etc/fstab (see the buig report), and this worked fine under 2.6.12-gentoo-r10, but when I upgraded to 2.6.13-gentoo-r3, then its back again, only slightly different.

This time, it will still accept my short password, and with the same "friendly" warning message, but then it cannot recognize the filesystem. Even when I specify the filesystem type, reiserfs cannot find a valid superblock, so this means that the crypto is not working with the short password.

It is worth mentioning that the latest upgrade also upgraded to mount-2.12r, but that when I boot my old 2.6.12-gentoo-r10 kernel, this new mount still works, so the problem this time is in the kernel. :evil:

I am filing a new bug report on this, as it is a slightly different problem. See bugzilla bug ???

steveb · Advocate Joined: 18 Sep 2002 Posts: 4564

Why don't you downgrade your kernel AND your mount package and then reboot with the old kernel and the old mount command and then change the password to a longer size and then you can easy update to the new kernel and the new mount command?

cheers

SteveB

Moriah · Posted: Wed Oct 12, 2005 7:10 pm Post subject:

While that would work for my online drives, that is totally unfeasible for several hundred encrypted backup dvds. The developers have forgotten that one major use for encrypted filesystems is offline backups. These backups need to be readable for at least 5 years. This means that legacy support for filesystem encryption must be provided for at least that long, and under current kernels, so one doesn't have to keep old systems around and running for 5 years just to be able to read backup files. Seven years would even be better.

steveb · Advocate Joined: 18 Sep 2002 Posts: 4564

Moriah · Posted: Thu Oct 13, 2005 5:27 pm Post subject: a clumsy workaround

Well, I guess a clumsy workaround would be to have a system with 2 dvd drives, or at least a cd rom drive and a dvd rom drive. That way, you could always boot an old livecd to read the backup dvds. And then, of course, you would also need a network card so you could copy the retrieve backups to the place where you wanted to put them.

But this is ugly, and it is much more desirable to be able to just stick an old backup dvd into the backup server's dvd drive and read what you want off of it (provided you know the password!).

Converting the drives in the raid array to a new password is fine in a lab environment, but in a production environment, you do not want to take the backup server down to do this. Remember, the on-line drives keep 60 to 90 days worth of backups online at all times, so that is quite a hunk of data to have to copy. Furthermore, due to the way it is stored -- to save space by sharaing identical files using hard links -- you cannot just simply copy each file over. You either need an identically sized raid and use dd, or you need to go through an extremely lengthy process to preserve the hard link topology. An in-place conversion is ruled out because you would have to back the whole thing up first in order to be able to safely do that, so you might as well just copy the raid in the first place.

Right now, I have almost 2 TB of backed up stuff online on my backup server. It backs up my network every night.