Extremely dangerous! cryptswap killed my partition
Bug #474258 reported by
Whitehat
This bug affects 19 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cryptsetup (Debian) |
Fix Released
|
Unknown
|
|||
cryptsetup (Ubuntu) |
Fix Released
|
Critical
|
Ubuntu Foundations Team | ||
Precise |
Fix Released
|
Critical
|
Ubuntu Foundations Team |
Bug Description
Binary package hint: cryptmount
9.10 installed with encrypted "home".
Had root on /dev/sda1, swap on /dev/sda2, and manually created "data" partition on "/dev/sda3"
When I deleted /dev/sda2 partition (wanted to move swap to the second HDD) - ubuntu killed my "data" partition!
I suppose the problem is that /dev/sda3 became /dev/sda2 and the cryptswap utility just killed all the data (about 80 gigs!), because /dev/sda2 is in the /etc/crypttab file as a swap partition...
Cryptswap should check the type of partition before mounting it as swap.
Related branches
lp:~cezary0/cryptsetup/bugfix474258_refactored
Rejected
for merging
into
lp:~ubuntu-core-dev/cryptsetup/ubuntu
- Surbhi Palande: Pending requested
- Steve Langasek: Pending requested
-
Diff: 401 lines (+231/-76)2 files modifieddebian/cryptdisks.functions (+124/-76)
debian/test_cryptdisk.sh (+107/-0)
security vulnerability: | yes → no |
visibility: | private → public |
tags: | added: dataloss |
Changed in cryptsetup (Ubuntu): | |
assignee: | Surbhi Palande (csurbhi) → Ubuntu Foundations Team (ubuntu-foundations-team) |
tags: | added: rls-mgr-p-tracking |
tags: | added: rls-p-tracking |
Changed in cryptsetup (Ubuntu): | |
milestone: | none → ubuntu-12.04 |
Changed in cryptsetup (Debian): | |
status: | Unknown → New |
Changed in cryptsetup (Debian): | |
status: | New → Fix Committed |
Changed in cryptsetup (Debian): | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
This bug report really does not sound like it refers to the "cryptmount" package.
Specifically, "cryptmount" does not use the /etc/crypttab file for any purpose, nor does it include any utility called "cryptswap" (even though if offers similar generic functionality).
More generally, it would appear that the problem is a side effect of repartitioning the main hard disk and not updating configuration files that refered to existing partitions that had been reassigned. It doesn't sound realistic for repartitioning tools to attempt to inform all applications that depend on a particular partition being available that it has been renamed. This is surely the responsibility of the system administrator.
Naturally, I commiserate with the bug-submitter about the possible loss of 80GB of data.
However, the proposed solution of checking partition-types before "mounting" as swap does not seem to offer an effective protection against corrupting data held on raw devices, especially via loopback devices which don't directly have "types" in the same way as disk partitions. Similar risks would seem to apply to any system-management tool which writes to raw devices.