search

rfjakob / gocryptfs

Encrypted overlay filesystem written in Go
https://nuetzlich.net/gocryptfs/
MIT License
3.58k stars 254 forks source link

Are inode unique and persistent in reverse mode ? #606

Closed hpn789 closed 5 days ago

hpn789 commented 3 years ago

Hi, I would like to use gocryptfs in reverse mode for cloud backup and I would like to know if the inodes number are unique and persistent in the encrypted view? I would like to use "Smart rsync backup" (https://github.com/wapsi/smart-rsync-backup) which list files moved and renamed since the last time and this tools only works if inodes are unique and persistent. I searched in the documentation but did find the answer. Thank you for your help :)

rfjakob commented 3 years ago

Hi! The inode numbers are always unique for one reverse mount.

Under the following condition they are also persistent:

If there are mountpoints, the inode numbers depend on the order of file accesses.

EDIT: see https://github.com/rfjakob/gocryptfs/issues/606#issuecomment-925207979

hpn789 commented 3 years ago

Thank you for the answer, unfortunatly I have found that inode change when I mount, unmount and remount depending of what file I read first, is this normal ? (I'm on version 2.1 on debian 9 (omv))

rfjakob commented 3 years ago

No mountpoints inside?

hpn789 commented 3 years ago

No, I made i simple test : I have a folder "plain" with files tree

Init with : "gocryptfs -reverse -init plain" Make directory cipher and mounted with "gocryptfs -reverse plain cipher" with resulting files tree:

a) If I make :

b) If then I make :

The really close number shows it depends of the order of access. If I repeat a) or b) mutiple times it always gives me the same inode.

rfjakob commented 3 years ago

Version v2.1 right? ( https://github.com/rfjakob/gocryptfs/releases/tag/v2.1 )

rfjakob commented 3 years ago

Hmm, looks good here:

$ ./gocryptfs -version
gocryptfs v2.1 without_openssl; go-fuse v2.1.1-0.20210802120645-15a8bb029a4e; 2021-08-18 go1.17 linux/amd64

$ tree --inodes plain
plain
└── [143969475]  Test
    └── [143969476]  test.txt

$ ./gocryptfs -reverse plain cipher
Password: 
Decrypting master key
Filesystem mounted and ready.

$ tree --inodes cipher
cipher
├── [143969475]  8Zscd3_NV5YtsYE8Foe-ww
│   ├── [281475120680131]  gocryptfs.diriv
│   └── [143969476]  Xc1BUkX5f65xYtftpodE6w
├── [143969477]  gocryptfs.conf
└── [281475120680130]  gocryptfs.diriv

$ fusermount -u cipher

$ ./gocryptfs -reverse plain cipher
Password: 
Decrypting master key
Filesystem mounted and ready.

$ tree --inodes cipher
cipher
├── [143969475]  8Zscd3_NV5YtsYE8Foe-ww
│   ├── [281475120680131]  gocryptfs.diriv
│   └── [143969476]  Xc1BUkX5f65xYtftpodE6w
├── [143969477]  gocryptfs.conf
└── [281475120680130]  gocryptfs.diriv
hpn789 commented 3 years ago

gocryptfs -version : gocryptfs v2.1.HEAD; go-fuse v2.1.1-0.20210802120645-15a8bb029a4e; 2021-09-21 go1.17.1 linux/amd64

rfjakob commented 3 years ago

Can you run

tree --inodes plain

please?

hpn789 commented 3 years ago

I have not compile the without_openssl but I think it's the same. For your test the 2nd time do : "tree --inodes cipher/8Zscd3_NV5YtsYE8Foe-ww" not "tree --inodes cipher" because it access all file in the same order the 2 times in your exemple.

rfjakob commented 3 years ago

Good point, but no:

$ ./gocryptfs -reverse plain cipher
Password: 
Decrypting master key
Filesystem mounted and ready.

$ tree --inodes cipher/8Zscd3_NV5YtsYE8Foe-ww
cipher/8Zscd3_NV5YtsYE8Foe-ww
├── [281475120680131]  gocryptfs.diriv
└── [143969476]  Xc1BUkX5f65xYtftpodE6w
hpn789 commented 3 years ago

Can you run

tree --inodes plain

please?

It gives me 

tree --inodes plain
plain
└── [-2518476705809431667]  Test
    └── [-1819540082368938331]  Change.jpg

1 directory, 1 file

(sorry the file name is not Test.txt but Change.jpg)

rfjakob commented 3 years ago

Wow, negative inode numbers! That's something new!

What kind of filesystem is this?

hpn789 commented 3 years ago

Effectivly I'm on unionfs in this volume, I gonna try on an ext4 volume to see if it comes for this.

hpn789 commented 3 years ago

I think it come from unionfs because I rerun my test in a folder in ext4 volume and I have not the issue, so weird. 

# gocryptfs -reverse plain cipher
Password:
Decrypting master key
Filesystem mounted and ready.
# ls cipher/
gocryptfs.conf  gocryptfs.diriv  Jx0rm8L_M1_Q48OypQOeEg
# ls -il cipher/Jx0rm8L_M1_Q48OypQOeEg
total 8
       24119222 -rw-r--r-- 1 root users 55 sept. 22 20:40 4svlZfEWcwn-_KJn7KD8NQ
281475000829881 -r--r--r-- 1 root users 16 sept. 22 20:42 gocryptfs.diriv
# fusermount -u cipher
# gocryptfs -reverse plain cipher
Password:
Decrypting master key
Filesystem mounted and ready.
# ls -il cipher/Jx0rm8L_M1_Q48OypQOeEg
total 8
       24119222 -rw-r--r-- 1 root users 55 sept. 22 20:40 4svlZfEWcwn-_KJn7KD8NQ
281475000829881 -r--r--r-- 1 root users 16 sept. 22 20:42 gocryptfs.diriv
rfjakob commented 3 years ago

Oh I see. I forgot the 2nd condition for persistent inode numbers. So https://github.com/rfjakob/gocryptfs/issues/606#issuecomment-925001282 should have read:

The inode numbers are always unique for one reverse mount.

Under the following condition they are also persistent:

If there are mountpoints, the inode numbers depend on the order of file accesses.

hpn789 commented 3 years ago

Ok thank you, I gonna try to figure out a solution on my side, any idea why this limitation of "281474976710655" ?

hpn789 commented 3 years ago

For those who would have the same issue of non persistent inodes in encrypted folder when combining unionfs/mergerfs with gocryptfs in reverse mode I have found a solution.

If your have no mount point under the plain text directory the issues occurs when inodes are greater than "281474976710655" which is the max value on 48bits. The default conf of mergerfs calculate inodes on 64bits but you can add the parameters :

to mergerfs to always have 32bits inodes and be compatible with gocryptfs.

In the future, as more and more system use 64bits inodes I think gocryptfs should be compatible with them.

rfjakob commented 3 years ago

Yes, 281474976710655 is the max having 48 bits. Values above this are reserved for other things:

I read about how mergerfs generates inode numbers at https://github.com/trapexit/mergerfs#inodecalc . You should be aware that mergerfs does not guarantee unique inode numbers!

gocryptfs does guarantee unique inode numbers, but as a downside, it needs the reserved number range.

hpn789 commented 3 years ago

Yes, I'm aware that mergerfs does not guarantee unique inode numbers, until here I had no tools which making use of inodes or reporting issue. One more question, does gocryptfs guarantee uniques inodes number in the cipher view (reverse mode) even if the data in the plain folder are on mergerfs and so doesn't guarantee unique inodes?

rfjakob commented 3 years ago

does gocryptfs guarantee uniques inodes number in the cipher view (reverse mode) even if the data in the plain folder are on mergerfs and so doesn't guarantee unique inodes?

No!