Btrfs Send Stream v2 Support Queued Ahead Of Linux 5.20

[skeevy420]

Why not just create a ZFS block device and install another encrypted filesystem on it? eg ext4

There's little point. Your data is still encrypted. Just because all that metadata is able to be read doesn't mean the data is.

Think of it like this: imagine your disk is encrypted but the evil hackers still know all your mount points if they put your disk in another PC or boot up your PC with a Live environment. That's kind of how ZFS encryption works. They know that tank/home/username exists and that it mounts to /home/username but they'll have no idea what is at /home/username because ZFS will prompt for a password when they try to mount it. If you want to hide the fact that tank/home/username and its mount location even exist is why you'd want to put ZFS on LVM2.

Don't get me wrong, you can loop-mount another FS on top of ZFS, but, IMHO, for ease of use you'd be better of using KDE Vaults or something like that for the sensitive data you don't want people to access if you die at your PC with an active session running and the locker hasn't kicked in.

[oleid]

but they'll have no idea what is at /home/username because ZFS will prompt for a password when they try to mount it.

Do the directory structure below /home/username is encrypted as well? Or can you still read it (maybe with 3rdparty tools).

[skeevy420]

Do the directory structure below /home/username is encrypted as well? Or can you still read it (maybe with 3rdparty tools).

Yes, that's safe. The paranoia comes because $USERNAME could be sensitive information; a volume named tank/financial_records lets a hacker very heavily assume there are financial records stored there; zpools with custom properties lets an attacker know what to target and potentially even the OS used (like boot volumes tagged wtih Zectl's org.zectl:bootloader property). That's the kind of data that's leaked.

That said, I'm not going to claim that some data guru using their custom homemade tools won't be able to hack your pool...ZFS, LVM, or otherwise.

[Developer12]

There's little point. Your data is still encrypted. Just because all that metadata is able to be read doesn't mean the data is.

Think of it like this: imagine your disk is encrypted but the evil hackers still know all your mount points if they put your disk in another PC or boot up your PC with a Live environment. That's kind of how ZFS encryption works. They know that tank/home/username exists and that it mounts to /home/username but they'll have no idea what is at /home/username because ZFS will prompt for a password when they try to mount it. If you want to hide the fact that tank/home/username and its mount location even exist is why you'd want to put ZFS on LVM2.

Don't get me wrong, you can loop-mount another FS on top of ZFS, but, IMHO, for ease of use you'd be better of using KDE Vaults or something like that for the sensitive data you don't want people to access if you die at your PC with an active session running and the locker hasn't kicked in.

So no filesystem exists that encrypts it's metadata?

[evil_core]

So no filesystem exists that encrypts it's metadata?

LUKS is safest and most-performant.

But ZFS probably encrypts file sizes and directory structure (which could lead to watermarking attacks, etc, otherwise).

https://www.youtube.com/watch?v=frnLiXclAMo&t=387s

At least merceneary_sysadmin claims that:
https://www.reddit.com/r/zfs/comment...ve_encryption/

What you can't see is how many files are in datasetname, or what sizes and names they have.

There are also statements that it leaks approximation file sizes (rounded to recordsize or ashift value), and in case of compression its even more complicated:
https://www.reddit.com/r/zfs/comment...ol_encryption/

But I'm not ZFS expert.

[tildearrow]

No, it was not a controller or anything like this. I switched to ext4 on that drive and had no issues since then. It was around ~2 years ago. Funnily enough, in January someone switched to btrfs even though I told him to stay away from it had a total FS crash as well just after 4 months of using it :-)

Can you check whether there is silent corruption when using the ext4 file system? I am doubting whether the cause of Btrfs' failure is due to silent corruption (which Btrfs detects) or a bug in Btrfs...

[S.Pam]

Can you check whether there is silent corruption when using the ext4 file system? I am doubting whether the cause of Btrfs' failure is due to silent corruption (which Btrfs detects) or a bug in Btrfs...

No, ext4 does not check data against csum. The only way is to do shasum/md5sum on all your files as soon as they are are updated and then regularly check those checksums against the files. However with bad ram you can get bitflips and other corruption not detected by data-only csums.

[skeevy420]

So no filesystem exists that encrypts it's metadata?

Not my area of expertise. I just know how it works on ZFS. Basically, as long as you don't do something dumb like your volume "this_is_not_porn_pass_is_Aa123456" you'll likely be OK from everyone except three letter agencies with courts, drugs, a big $40 wrench, and the ability to threaten those you care about.

The Ultra Secure way with ZFS, or anything for that matter, would be Encrypted Disk<Encrypted FS<Encrypted Archive<Encrypted File(s). Every single one of those ways probably has a hack or workaround that can be figured out by someone so you gotta use them all. And you should be using different encryption schemes and passwords between layers -- just in case an exploit comes out you'll still have some secure layers between your file and the attacker