# 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.    :Crying or Very sad: 

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

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

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

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:

```
ezekiel ~ # strings /sbin/losetup | sort | grep character

Error: Password must be at least %d characters.

WARNING - Please use longer password (%d or more characters)

ezekiel ~ # 
```

So losetup is the villian!   :Evil or Very Mad: 

Now, I just need to scarf the source for losetup and add my own option to override the password length!

TA DA!

Now, I am not an emerge/portage expert.  I only administer a gentoo network so that I can have one handy to develop stuff on.  

First off, how do I get a list of previous versions of a program, such a losetup?  

Second, how do I get the sources of both the version with the 20 char pw requirement, and the version without it, so I can diff them and see where I need to add my override option -- perhaps named --shortpw?

Finally, what is the process to submit a bug fix or feature (whatever you want to call this) for inclusion into the next release?

----------

## Moriah

```
 # for x in `equery files util-linux | grep 'bin/' | awk '{print $1}' -`

> do echo -n "$x " ; strings $x | grep character ; echo ""

> done  | grep password

/bin/mount WARNING - Please use longer password (%d or more characters)

/sbin/losetup WARNING - Please use longer password (%d or more characters)

#
```

Therefore, I conclude that the same offending code gets patched into both mount and losetup, but not anything else in util-linux.

----------

## Moriah

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

----------

## Moriah

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 or Very Mad: 

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

----------

## steveb

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

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

 *Moriah wrote:*   

> 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.

 MUST?? Since when is this a MUST?

Anyway... if you are serious about backup, then you MUST enshure that you still have the possibility to restore the backup. So you NEED to enshure that you have the needed kernel, system, hardware, etc in order to restore that backup data.

I only see a problem (in your scenario): You can not restore old backups, but you still can backup the current data into a encrypted filesystem (you just need stronger password).

But I agree with you, that it would be nice if legacy support would be available.

cheers

SteveB

----------

## Moriah

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.    :Very Happy: 

----------

