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