gocryptfs reverse on ZFS problem

[rohanmperry]

When I reverse mount a ZFS file system that has child zfs filesystems mounted under it, and run a recursive find on the encrypted folder, it does not descend down to the child filesystem folder. Find gives the error:

find: File system loop detected; "" is part of the same file system loop as "."

Even 'ls -lR ' gives a similar error.

I've tried to recreate the problem with hierarchically mounted ext4 fie systems, but it seems to happens only for ZFS. Perhaps it has something to do with ZFS. I've notices all ZFS child mount points have the same i-node number.

Is there a work around for this problem?

[rfjakob]

Hmm, could you post the stat output for one file inside the parent and one file inside the child zfs filesystem? Also, which gocryptfs version do you run (gocryptfs -version)?

[rohanmperry]

I checked the version (1.7.1) and I just upgraded it to the latest version (1.8.0) and the problem disappeared! Thanks!

However, now I have a new problem. Though all the plain text ZFS child mount points have the same i-node number (34 as shown by ls -i), you seem to pad a lot of bits to the left of it to make a really massive number. These bits are different for different mount points, I use i-node numbers to find out the encrypted file for a given plain text file. By stripping the high order bits I can get the original i-node number, but I cannot figure out exactly how many bits to strip. Can you please let me know how many high order bits I should strip?

For instance, my original plain text ZFS child mountpoints all have the same i-node number which is 34.

After reverse mounting the i-node numbers for the corresponding folders for the zfs child mount points become:

844424930132002
281474976710690
562949953421346
1688849860263970
1407374883553314
1125899906842658

All these numbers have the last low order bits of 100010, which is 34 (decimal), but I can't figure out exactly how many bits to strip, since there are a lot of zeroes in the middle.

This seems to be the case even for other files that are not ZFS mount points.

[rfjakob]

Format is like this since gocryptfs v1.8:

[0][15 bit device id][48 bit passthru inode number]

so you want the lower 48 bits for the original inode number.

However, this is an internal detail and not guaranteed to stay like this in future versions of gocryptfs.

Have you considered using gocryptfs-xray -encrypt-paths ?

[rohanmperry]

Thanks for the info.

Actually, gocrpyfs-xray option would be the perfect solution. However, my version does not have the encrypt/decrypt-paths options. I can't find a place to download the binary of xray. The archive "gocryptfs_v1.8.0_linux-static_amd64.tar.gz" has only the latest gocryptfs binary.

[rfjakob]

This was also requested in #496 , time to do something about it :)

Here you go, never mind the beta version, the changes for v2.0 do not affect gocryptfs-xray:

gocryptfs_v2.0-beta2-30-ge0981ea_linux-static_amd64.tar.gz

The gocryptfs v2.0 final release and future releases will also include gocryptfs-xray.