State of native encryption in ZFS

Niall Douglas s_sourceforge at nedprod.com
Sun May 15 10:48:48 UTC 2016


On 14 May 2016 at 16:09, K. Macy wrote:

> >> It’s not even clear how that encryption would be implemented or exposed.
> >>  Per pool?  Per dataset?  Per folder?  Per file?  There have been
> >> requests for all of the above at one time or another, and the key
> >> management challenges for each are different.  They can also be
> >> implemented at a layer above ZFS, given sufficient interest.
> >
> > If FreeBSD had a bigger PATH_MAX then stackable encryptions layers
> > like ecryptfs (encfs?) would be viable choices. Because encrypted
> > path components are so long, one runs very rapidly into the maximum
> > path on the system when PATH_MAX is so low.
> >
> > I ended up actually installing ZFS on Linux with ecryptfs on top to
> > solve this. Every 15 minutes it ZFS snapshot syncs with the FreeBSD
> > edition. This works very well, apart from the poor performance of ZFS
> > on Linux.
> >
> > ZFS handles long paths with ease. FreeBSD currently does not :(
> 
> AFAICT that's a 1 line patch. Have you tried patching that and
> rebuilding kernel, world, and any vulnerable ports?

The problem is apparently kernel structure bloat and that they want 
to remove fixed maximum paths altogether so it would be boot 
modifiable.

http://freebsd.1045724.n5.nabble.com/misc-184340-PATH-MAX-not-interope
rable-with-Linux-td5864469.html

As laudable as the latter goal is, unfortunately OS X and Linux hard 
code theirs, and much POSIX software will use whatever PATH_MAX is 
set to. I'm therefore not sure the implementation cost is worth it.

In any case, a 1024 byte path limit is just 256 unicode characters 
potentially. That's worse than Windows 95 :(

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: SMime.p7s
Type: application/x-pkcs7-signature
Size: 6360 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160515/19084c61/attachment.bin>


More information about the freebsd-fs mailing list