mount.crypt needs to pass -s to cryptsetup

[Kenny Millington]

mount.crypt needs to pass the -s option to cryptsetup or in some cases mount.crypt fails to mount the encrypted volume. In my case this is where I've used a keysize of 128 bits, but 256 is the default so unless something tells cryptsetup the keysize is 128, it proceeds to assume/use the default of 256 and thus mounting the encrypted volume fails.

This was fixed upstream in the following commitdiff:-

http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount;a=commitdiff;h=91a318a05cde0382c086a8bf169b3cff08c8b835

I've re-based this fix against the Jaunty version of libpam-mount and I'll attach a debdiff once this bug is logged so I know the LP bug number.

[Kenny Millington (kmdm)]

Jaunty test package with the debdiff applied has now been submitted to my PPA.

[jcfp (jcfp)]

Was hit by this one when updating from intrepid. Apparently went fine until I discovered that in jaunty only one of my encrypted partitions was being mounted, namely the one with a 256 bit keysize. None of the others did, took me well into the night fearing all data on those disks was lost before finding this bug report putting me on track to the solution.

The patch doesn't appear to work for me though, it does cause a "-s" parameter to be used but with the wrong bitsize (104 instead of 448). Manually, everything works again when using the cryptsetup command when setting the hash parameter to ripemd160 and using the -s options with the correct keysize.

Overall, this is a severe regression, updating from a perfectly working system without any useful warning users end up with apparently unusable encrypted partitions; getting error messages like "mount: you must specify the filesystem type" suggesting there is no recognisable data on disk or some kind of severe filesystem corruption. This really needs to be fixed!

[Kenny Millington (kmdm)]

@jcfp:

Strange, so if you run "mount.crypt" manually from the command line with the attached patch it (mysteriously) passes through 104 instead of 448?

Can you paste the output of running the mount.crypt command with the -v parameter? Just curious to see what's going on there since it works absolutely fine for me. :-/

[jcfp (jcfp)]

For ages had the following in pam_mount.conf (old non-luks):
volume me crypt - /dev/sdb1 /mnt/massa_crypto-2 cipher=blowfish-cbc-essiv:sha256,keysize=448 - -

Until that didn't work anymore after upgrading to jaunty (crashes reoprted in syslog, similar to #353935), even when trying manually and adding ripemd160 for the hash that apparently nowadays defaults to "plain" otherwise:
# /sbin/mount.crypt -v -o cipher=blowfish-cbc-essiv:sha256,hash=ripemd160,keysize=448 /dev/sdb1 /mnt/massa_crypto-2
mount.crypt(mtcrypt.c:149): keysize mount option ignored
command: [readlink] [-fn] [/dev/sdb1]
command: [readlink] [-fn] [/mnt/massa_crypto-2]
Password:
mount.crypt(loop.c:319): Using _dev_sdb1 as dmdevice name
command: [cryptsetup] [-c] [blowfish-cbc-essiv:sha256] [--key-file=-] [-h] [ripemd160] [create] [_dev_sdb1] [/dev/sdb1]
command: [mount] [-n] [/dev/mapper/_dev_sdb1] [/mnt/massa_crypto-2]
mount: you must specify the filesystem type
mount failed with exit status 32

With your patch added, the result is this:
# /sbin/mount.crypt -v -o cipher=blowfish-cbc-essiv:sha256,hash=ripemd160,keysize=448 /dev/sdb1 /mnt/massa_crypto-2
mount.crypt(mtcrypt.c:149): keysize mount option ignored
command: [readlink] [-fn] [/dev/sdb1]
command: [readlink] [-fn] [/mnt/massa_crypto-2]
Password:
mount.crypt(loop.c:325): Using _dev_sdb1 as dmdevice name
command: [cryptsetup] [-c] [blowfish-cbc-essiv:sha256] [--key-file=-] [-h] [ripemd160] [-s] [104] [create] [_dev_sdb1] [/dev/sdb1]
command: [mount] [-n] [/dev/mapper/_dev_sdb1] [/mnt/massa_crypto-2]
mount: you must specify the filesystem type
mount failed with exit status 32

Althought the key here seems to be "mount.crypt(mtcrypt.c:149): keysize mount option ignored", which might well have nothing to do with your patch, I can't see where it's getting this value "104" from. Doing cryptsetup and mount manually as follows:
# cryptsetup -c blowfish-cbc-essiv:sha256 --key-file=- -h ripemd160 -s 448 create _dev_sdb1 /dev/sdb1
# mount /dev/mapper/_dev_sdb1 /mnt/massa_crypto-2

...turned out to work flawlessly, like my other encrypted partitions using "cipher=twofish-cbc-essiv:sha256,keysize=256" (with luks) had been doing all along.

[Jan Engelhardt (jengelh)]

Your patch is flawed, it makes the key_size array too small.

[Kenny Millington (kmdm)]

Could very well be, upstream used the constant HXSIZEOF_Z32, I merely used the value of that constant in the created debdiff which was -4294967296.

If indeed it is flawed here then it's arguably also flawed upstream so please do consider reporting it there as well.

[Kenny Millington (kmdm)]

Worth noting is two other commitdiffs from upstream that re-add support for overriding the keysize (and then fixing the first patch) - the use-case for this is given with an example keysize of 448:-

(Re-)Add support for overriding keysize:-

http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount;a=commitdiff;h=d8e738c4aaaed7c259511976c59c06864dccaed7

Fix support:-
http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount;a=commitdiff;h=6d347f2b514a8855450b04be42ce7ec8ca7dc593

The first is in pam_mount v1.22, the second in pam_mount v1.24

[Kenny Millington (kmdm)]

Discussion for the latter changes:
http://sourceforge.net/tracker/?func=detail&aid=2727353&group_id=41452&atid=430594

[Steve Langasek (vorlon)]

Are those latter changes needed as part of this fix? If so, can you provide them as part of a complete debdiff?

[Steve Langasek (vorlon)]

My understanding is that this bug is fixed upstream in the karmic version. Opening a jaunty task for prospective SRU.

[Steve Langasek (vorlon)]

marking 'incomplete' for the open question about whether the other upstream cherry-picks are needed.

[Kenny Millington (kmdm)]

@Steve:

Thanks for taking a look at this bug.

In my opinion the other upstream cherry picks are not needed to pass -s to cryptsetup (I've been running with the first/original fix for several months now without issue).

I believe the other cherry picks are a separate but very closely related bug in mount.crypt - for that reason it could very well make sense to apply all the fixes in one SRU rather than two.

All that being said I would welcome comments and/or better suggestions from j.engelh as the (apparent) upstream maintainer as well as clarification of his comment on 2009-06-08 about the key_size array being too small because if indeed it is and my use of the constant value is flawed then my debdiff needs correcting.

(Please note I'm not a C coder by any stretch of the imagination but I can read/understand it and apply patches from newer code revisions etc...)

[Benjamin Drung (bdrung)]

I unsubscribed ubuntu-sponsors, because there is no debdiff to sponsor.

[Kenny Millington (kmdm)]

As attached:-

http://launchpadlibrarian.net/26008536/LP367577.patch

...is a debdiff.

I've long since moved to karmic (where the issue is fixed) so my interest in this bug as waned since then.

But, if that debdiff isn't valid for sponsoring I'd very much appreciate an explanation so I don't make a similar mistake in future. :)

[JC Hulce (soaringsky)]

Thank you for taking the time to report this bug. This issue has been fixed in newer versions of Ubuntu, and Jaunty is EOL. Thus, I am closing this bugtask.