Unable to encrypt partitions on loopback device

[michaeladler]

I'm unable to encrypt a partition on a loop-back device (this is part of an integration test where I want to avoid having a physical disk):

Steps to reproduce:

$ truncate -s512M backing_file
$ losetup --find --show backing_file
# assume it's /dev/loop0
$ parted /dev/loop0 --script -- mklabel gpt
$ parted /dev/loop0 --script -- mkpart primary 0 -1
$ partprobe
$ zuluCrypt-cli -c -d /dev/loop0p1 -z ext4 -t vcrypt -p test
ERROR: Could not open volume for writing

This scenario works using the veracrypt binary instead. A quick strace revealed:

openat(AT_FDCWD, "/sys/block/loop0p1/loop/backing_file", O_RDONLY) = -1 ENOENT (No such file or directory)

Of course, this file is not supposed to exist but zuluCrypt seems very unhappy about it :( In fact, I would prefer if there was an option to tell zuluCrypt not to attempt creating any filesystems (i.e. just open the provided device and write directly to it).

Affected version: 5.4.0

[mhogomchungu]

How do i create a device that looks like /dev/loop0p1? I do not think zuluCrypt can to handle such a device.

I would prefer if there was an option to tell zuluCrypt not to attempt creating any filesystems (i.e. just open the provided device and write directly to it).

It is already possible to unlock a volume without mounting it. The option to unlock a volume and mount is -o and the option to unlock without mounting is -O, why do you want to create a volume without putting a file system on it?

[michaeladler]

How do i create a device that looks like /dev/loop0p1? I do not think zuluCrypt can to handle such a device.

If you follow the "Steps to reproduce" in the original post, you will end up with loop0p1. The suffix p1 just means the first partition on /dev/loop0 (compare this to e.g. /dev/sda1 which is the first partition of /dev/sda). You are right, zuluCrypt cannot handle this, but it should and therefore this bug report. Both cryptsetup and veracrypt can do this. From the point of view of the cryptographic software, /dev/loop0p1 should be considered the same as a partition of a physical device, e.g. /dev/sda1. zuluCrypt can already handle the case of /dev/loop0, but it fails for partitions of loop0.

It is already possible to unlock a volume without mounting it. The option to unlock a volume and mount is -o and the option to unlock without mounting is -O, why do you want to create a volume without putting a file system on it?

I know about the -O option. I do want to put a filesystem on it, but I might not want to use the defaults provided by mkfs.XXX. For instance, if you use mkfs.fat, you might want to add -F 32 to enforce a 32 bit file allocation table instead of relying on auto-detection (which means giving up reproducibility). cryptsetup follows this approach as well, i.e. it simply sets up the device-mapping in /dev/mapper/ and you can then do whatever you want with it. While the approach zuluCrypt chooses might be comfortable for regular users, it certainly is an annoyance for power-users: If you want to create a custom filesystem on it, you are forced to wait for the mkfs.xxx spawned by zuluCrypt to finish and then wait again for your custom mkfs.yyy. On a 5TB partition, this means waiting quite some time.

[mhogomchungu]

The git version now supports loop device paths that are in /dev/loopXpY format. zuluCrypt previously supported paths that were only in /dev/loopX format.

The solution was simply converting the former format to the latter because /sys/block/loop0/loop/backing_file exists but /sys/block/loop0/loop0p1/backing_file doesnt.

[michaeladler]

The solution was simply converting the former format to the latter because /sys/block/loop0/loop/backing_file exists but /sys/block/loop0/loop0p1/backing_file doesnt.

I'm skeptical that this is the right solution. If you convert /dev/loop0p1 to /dev/loop0, you will end up encrypting the whole "device", i.e. all of /dev/loop0, right? This is not the desired behavior though, e.g. I'd like to have two partitions on /dev/loop0, one being unencrypted and one being encrypted using zuluCrypt.

[mhogomchungu]

I'd like to have two partitions on /dev/loop0

The problem was with getting a backing file of a loop device, /dev/loop0p1,/dev/loop0p2 and /dev/loop0p3 all have the same backing file and it is located at /sys/block/loop0/loop/backing_file and the path to this backing file is the same path as if the loop device has a path of /dev/loop0.

Try it and it works.

For security reasons, after zuluCrypt has opened an image file, it does not look at the path of the image file by looking at the path it was given by the user but by asking the operating system for the path and it i asking by reading /sys/block/loopX/loop/backing_file file.

When it comes to doing the encryption part, loop device paths are the ones that are getting used.

[michaeladler]

I just compiled the master branch and tested your fix. You are right, it works! Thanks a lot.

Regarding the issue with the automatic creation of filesystems, maybe you could add a special filesystem "none" and then skip the filesystem creation? I know this is actually a separate issue, but I figure I'd mention it while we're at it ;)

[mhogomchungu]

The git version now supports "none" file system. Use it to create a volume with no file system in it. When creating a volume, use option -z none.

[michaeladler]

Awesome, thanks again! I just tested it successfully. I'm hereby closing this issue.

[mhogomchungu]

An update on this issue.

zuluCrypt will now not resolve partitioned loop devices and users will see them as they are.