wired behavior of passphrase encrypted dataset

[klatoszy]

This affects all my TrueNAS Core 13.0U3 and 13.0U3.1.

I encrypt my pool/root dataset using ZFS native encryption with key. Child datasets inherit encryption from parents.

No I want to keep sensitive data inside dataset that can be easily locked - that is why I create child dataset encrypted with pathphrase. Until now all is ok.

Wired things start when I lock dataset protected by passphrase. No matter if I select "Force unount" or not while locking dataset it is still visible in file system. What is more I can simply enter this dataset and create new files inside (despite te fact that in UI I can see padlock closed indicating dataset is locked). Then when I unlock this dataset, new direcory with dataset name appended with unlock date, time and some random characters is created. This new folder contains all data that was put inside passprase protected dataset whlie it was locked. New folder is created everytiem I put anything inside dataset while it is locked. This is 100% reproducible.

So basically lock/unlock work fine and content of passphrase dataset is ok. But while locked dataset is still available in file system in rw mode and this can misslead users.

Is that a bug and I should file ticket to fix? Or I am doing something wrong?

 

[Arwen]

I may be mis-reading what you wrote...

Are you sure the Locked Dataset is still mounted?

From the command line, you can use this command df -h to see if your Locked Dataset is still mounted.


Unix uses a concept of mount points, which is a directory that is used by a file system when the file system is mounted. However, if the file system is un-mounted, (which should be the case when you Lock a Dataset), the directory still remains but should be empty.

Some Unix flavors allow writing into a mount point directory, and then allow a file system to be mounted on top. This can cause hidden space usage that can't be cleaned up unless the file system is un-mounted.

 

[klatoszy]

Are you sure the Locked Dataset is still mounted?

From the command line, you can use this command df -h to see if your Locked Dataset is still mounted.

When I run df -h then locked dataset is not mounted anymore.

Unix uses a concept of mount points, which is a directory that is used by a file system when the file system is mounted. However, if the file system is un-mounted, (which should be the case when you Lock a Dataset), the directory still remains but should be empty.

Yes, directory is empty after unmount.

Some Unix flavors allow writing into a mount point directory, and then allow a file system to be mounted on top. This can cause hidden space usage that can't be cleaned up unless the file system is un-mounted.

This is exactly my observation. I can read/write into mount point directory when dataset is unmounted. This can be misleading and security issue. Even if dataset is locked and unmounted, some user can write to mount point directory thinking they write into mounted passphrase protected dataset. From end user perspective path is the same.

 

[Arwen]

Okay, what you are seeing is normal.

The way this is generally dealt with is that the parent directory and mount point directory are generally owned by "root", and don't have group or world write permissions. Further, in some cases you would share the ZFS Locked Dataset, not the mount point. So normal users would not even be able to map / mount the share while the Dataset is Locked. And even if they could access a share from say a parent directory, with owner as "root" and no group or world write permissions, they should not be able to write any files.

When the Locked Dataset is un-locked, (thus also mounted on to the mount point directory), it brings with it, it's own ownership and permissions. And any share associated with it.

Now the details of how TrueNAS deals with native ZFS encryption, locked datasets, mount points and shares is a bit beyond me. Perhaps someone else can chime in.

It is possible your problem arises because you have shared the parent ZFS dataset. There are times when nested datasets are not the appropriate solution. This may be one of them.

 

[c77dk]

How do you access the "unmounted" (the one not encrypted) dataset? Directly on the TrueNAS host, or via CIFS/NFS ? I remember there was an issue then 12.0 was in RC, where CIFS/NFS would start without unlocked datasets, and create the situation you describe. This was resolved then, but dependent of your access pattern it might have been reverted.

 

[klatoszy]

So far I was testing from root account without proper sharing and/or setting permissions. It is likely as @Arven pointed that when accessed as non-root account all will be fine. I will check that later on today.

On the other side - when I replicate locked dataset then on target TrueNAS it is locked and root does not see mount directory. Only when such dataset is unlocked then mount directory shows up. Is that behavior exclusive to replication?

 

[Arwen]

...

On the other side - when I replicate locked dataset then on target TrueNAS it is locked and root does not see mount directory. Only when such dataset is unlocked then mount directory shows up. Is that behavior exclusive to replication?

If the destination never had the mount point directory, then I would guess yes. After replication where the dataset is sent encrypted, (aka Locked), then it would not automatically create the mount point directory.

However, if their was a recursive ZFS Send & Receive, (aka Replication), and the Locked Dataset was not the top level, then the parent directory should replicate the mount point of the Locked Dataset.

 

[klatoszy]

I checked how it works when I used non-root access and shared using SMB.

Dataset unlocked - SMB share is available and I'm able to read/write files.

Dataset locked - SMB share disappears from available shares.

My problem was that initial test was done using root account while for non-root access behavior is different.