Tomb refuses to open a tomb without -f flag with implicitly encrypted swap

[fsLeg]

My system resides on an encrypted partition, within which resides LVM, within which reside all my volumes: root, home and swap. Thus, my swap is encrypted. But Tomb doesn't detect that, because it can only detect explicitly encrypted swap.

Can Tomb conduct a deeper analysis of swap partitions? Or would it be too much of an effort, and users of such setups will have to use -f option?

[jaromil]

Won't be fixed in the next release, but later on maybe. Meanwhile use of -f to manual specify will stay.

[deadcyclo]

I'm quite interested in such a feature as well. Could one not simply use sudo dmsetup status to determine if swap is encrypted?

[jaromil]

hi :^)

can you providea tested example to detect?

the only reason why this is still pending is that no developer has this setup and can reproduce it.

more in general the swap detection is @hellekin's code.

[hellekin]

Well, actually I do have access to this setup, but I'm not sure how to trace back a swap partition to an LVM volume. I'm thinking of going from cat /proc/swaps to detect active swap to blkid -t TYPE=swap to get the UUID of /dev/dm-* and /dev/mapper/* to check against LVM information using lvdisplay and vgdisplay... E.g., dmsetup status will tell me whether a VG is crypt or not. So if I can relate these informations together, that should be doable. I just need to find the right options.

[boyska]

I'm not sure how to trace back a swap partition to an LVM volume.

lsblk does this. Of course parsing it can be not so easy, still...

[boyska]

mh, look at this. If you want to know if /dev/mapper/myswap is encrypted, you could lsblk --inverse /dev/mapper/myswap (--inverse is quite important here) and see if something has type "crypt". This can be done more easily with lsblk --inverse -o TYPE -n $dev|egrep -q '^crypt$'

Unfortunately, I see that --inverse is not present in debian wheezy (that is, util-linux=2.20). In arch (version 2.25) this option is present. The same version is in debian jessie, so I expect the option to be there, also. Can not be sure, though.

[hellekin]

Awesome. Exactly what is needed. It also will simplify the check.

[deadcyclo]

Heh. I went to bed yesterday planning on using my evening today creating a fix. Glad I checked this thread first ;)

[hellekin]

Heh... I think I just destroyed some praised code by making it better. ;o)

I updated the fix to use lsblk in all cases. That means this bug is fixed for util-linux >= 2.22 but not before (e.g., at this time Debian Wheezy or Slackware64 14.1). But as the -f option is available, people with plain swaps on encrypted volumes can simply use that option. I added a reminder to point at this issue.

[jaromil]

Lets wait a bit that everyone has the time to test this. Please let us know!

Extensive testing can also be done by script:

cd extras/test
sudo make

[jaromil]

OK. Can this be closed then?

[fsLeg]

@jaromil I don't think so. The current solution relies on util-linux >= 2.22, which isn't the case for some major distributions.

[jaromil]

we either remove all the patching done (which was messy) and stay with old behaviour, or move forward by supporting the future systems and tell people to use -f if util-linuz is old.

I'd rather not merge this branch and leave things as they are for a while longer

[hellekin]

@FsLeg as mentioned in the comments, if you don't have util-linux >= 2.22, the code reverts to the old behavior, which is to tell the user to use -f. I don't think we want to spend more time on solving it any differently.

[jaromil]

I don't understand. What is PR doing? Correct me if I'm wrong

1- Checks using old method
2- Checks using new method
3 asks to use -f

is all three steps, so just a check is stacked? Or 1 and 2 are mutually exclusive?

[hellekin]

On 02/16/15 17:22, Jaromil wrote:

I don't understand. What is PR doing? Correct me if I'm wrong

1- Checks using old method
2- Checks using new method
3 asks to use -f

*\ 2 - 1 - 3.

It first checks whether util-linux is >= 2.22. If it is, then it can detect plain swaps over encrypted volumes, and if that's the case, it returns 2 -> safe swap.

If it does not have that functionality, it checks using the old method: if there's a plain swap over an encrypted volume, it cannot detect it, so it returns 1 -> unsafe swap, and warns the user that it might be the case. As the user should know that kind of setup, they can use -f in that case.

When enough OSes have updated their util-linux, this legacy case will fade away.

hk

We are free to share code and we code to share freedom (X)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/

[jaromil]

ok! I misunderstood, thanks for clarifications. I think is ok now then. have you ran tests on different setups? i haven't tested yet.

[hellekin]

As commented on the pull request, the new code correctly identifies blocks, but not files.

[hellekin]

All right, as explained in the pull request !189 the code covers this issue. But if you're using a plain swapfile on an encrypted filesystem you're out of luck and need to use -f anyway.

And don't trust @jaromil when he tells you it won't be implemented in the next release ;o)

[jaromil]

:^D well done

[boyska]

By the way, what do you mean with "plain swapfile"? is there something like a non-plain swapfile? Or is there something like a non-plain swap partition? I think they're always plain; when they're encrypted, it's always some ancestor block device that is encrypted. Am I wrong?