[dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data

ken gebser at mousecar.com
Thu Dec 27 10:35:51 CET 2012


This seems it would be an easy mistake to make, especially if one's 
working on an unfamiliar system or multiple heterogeneous systems or 
after a long time during which dm-crypt has been working, as it should, 
transparently and its presence is forgotten.  I could see myself making 
the same mistake.  So thanks for bringing up the issue.

This will likely be the least knowledgeable reply you'll get, so please 
defer to any other replies.

I would think that the most assured method to prevent this mistake would 
need to be from the side of fsck itself.  So I would rename fsck to 
something else, say fsck.bin.  Then a shell script would call fsck.bin 
after first checking the device specified.  One check I can think of 
would consist of an attempt to mount the specified device to a temporary 
mountpoint.  Only if the mount succeeds, after the device is unmounted, 
would fsck.bin be called.  Of course each of the various 
fsck.{filesystem} executables should get this sort of wrapping.

True, this is a bit of a cludge.  And there's probably two or three more 
elegant cludges possible.  And a true fix would need to be incorporated 
into all the fsck.{filesystem} executables themselves.  But that would 
probably take awhile to happen and then flow out to all the distros. 
Something like the above might serve the purpose until all that happens.

On 12/27/2012 01:12 AM Emily Williams wrote:
> Today I made a rather large mistake, running fsck.ext4 on the raw volume
> (/dev/sdk1) instead of the mapped volume
> (/dev/mapper/whatever-i-choose-to-call-it). I assume it is not possible
> to recover from this once it is done and the cryptosetup lukeOpen
> passphrase no longer works.
> I'd like to avoid this ever happening in the future. Is there any way to
> put in safeguards to minimize the chance of this ever happening again?
> I've found very few references to this problem after a lot of searching
> - below is one I did find that at least made me think I wasn't going
> crazy - so I'm guessing I'm just doing something silly that makes
> fsck.ext4 think that the raw volume is actually something it should take
> a whack at fixing, instead of saying something sensible like "that
> doesn't look like an ext4 filesystem, go away", which as far as I can
> see should be the case - it's encrypted, so it shouldn't "look like"
> anything except crypto_luks metadata and random data in no discernible
> format. And yet fsck.ext4 seems to be behaving as though it sees an ext4
> filesystem with errors.
> From: poptones
> Subject: (not LUKS) why did fsck on an encrypted source work?
> Date: 2005-11-15 06:26:26 GMT (7 years, 6 weeks, 5 hours and 28 minutes ago)
> Accidentally (yes, I was still a little rattled from the
> earlier mistake) I ran this on /dev/md0 instead of /dev/mapper/md0.
> After a couple of hours it began the final pass and I saw it report
> moving files - about 20,000 object moved to /lost&found.
> Somewhat perplexed and confused, and learning not to play with new toys
> when overtired,
> -Emily
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

More information about the dm-crypt mailing list