(Cc: debian-boot@ added.) Martin Pitt <mp...@debian.org> (2015-04-16): > Hello release team,
(With my d-i release manager hat.) > yesterday I discovered that systemd breaks a common way of setting up > plain cryptsetup partitions. Turns out that this has already been > known for a while, but the impact wasn't appreciated enough: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707 > > What happens is that systemd's cryptsetup integration ignores the > "offset=" parameter in crypttab and instead uses the whole device. So > if you had a swap or other partition underneath in order to identify > the partition via UUID or label instead of an unreliable hardcoded > device name, switching to systemd destroys the underlying metadata, > and causes a boot hang as crypttab now refers to a nonexisting > UUID/label. This is quite a common way to set up encrypted swap, the > way that ecryptfs' own swap setup tool does it (the Ubuntu installer > calls that if you select "encrypt my home directory"; I'm not sure > whether Debian's installer does the same). Grepping for hash= in partman-* d-i packages led to partman-crypto, which seems responsible for this (no surprise here): http://anonscm.debian.org/cgit/d-i/partman-crypto.git/tree/finish.d/crypto_config There's no offset= there. Looking into partman-* in Ubuntu vivid, it turns out that one of them look at user-setup, and that's where the following is defined: | Template: user-setup/encrypt-home | Type: boolean | Default: false | # :sl2: | _Description: Encrypt your home directory? `---[ debian/user-setup-udeb.templates ]--- which is then used in user-setup-apply where there's a lot more (encryption-related) code than in Debian, which e.g. calls adduser with an option to encrypt home, which then calls some commands from the ecryptfs-utils package, but I don't see any offset in the ecryptfs-setup-private script. Anyway, asking for home encryption indeed leads to swap encryption, through a ecryptfs-setup-swap call, which in turn triggers: | echo "cryptswap$i UUID=$uuid /dev/urandom swap,offset=1024,cipher=aes-xts-plain64" >> /etc/crypttab `---[ src/utils/ecryptfs-setup-swap ]--- The same file in the Debian package has no offset, so I guess that means Debian is rather safe. > IMHO this qualifies as data loss, and we cannot repair this > automatically after the damage happened. So I'd really like to fix > this in jessie, and I upgraded it to RC. > > The patch is quite straightforward. It got a first review by upstream, > I made it a bit more defensive since the first version, and it'll > probably land today. I attached my test script to the upstream bug [1] > which allows you to play around with various offset= options and > verify that it doesn't destroy the initial part of the partition. > > I realize this is a somewhat awkward timing as we want to deep-freeze > in two days, and this means an udeb change (although only formally as > there are no effective changes in udev). 215-16 should go into testing > tonight, and I'm prepared to upload 215-17 with that fix right after > that with urgency=high. > > What would you recommend how to proceed? Provided a review by the release team, I'm OK with letting this go into testing between D-I Jessie RC3 (to be released at the end of this week) and a possible extra debian-installer upload (before the release). I'm not exactly entirely sure how to deal with D-I for Jessie past RC3 anyway: - Do nothing? - BinNMU to make sure it's built against last-migrated components? - Sourceful upload in case there's any changes staged in git during the last week? (I hope that won't be necessary.) Mraw, KiBi.
signature.asc
Description: Digital signature
