Date: Tue, 17 May 2016 11:37:54 +0100 From: Niall Douglas <s_sourceforge@nedprod.com> To: freebsd-fs@FreeBSD.org <freebsd-fs@freebsd.org> Subject: Re: Bigger MAX_PATH (Was: Re: State of native encryption in ZFS)
| raw e-mail | index | archive | help
On 17 May 2016 at 11:58, Ben RUBSON wrote:
> >>> 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.
>
> Could you give us some examples where PATH_MAX was too low for you using ecryptfs ?
> I (for the moment) do not run into troubles using EncFS.
Sure.
I typed this command into my encrypted store to find all paths and sort
them by length:
find . | awk '{ print length, $0 }' | sort -n -s | cut -d" " -f2-
And this was the last (longest) path returned:
./ECRYPTFS_FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6advEpfCnjqSMVUiW5.LgoJrMb2-r
t6c61qRU--/ECRYPTFS_FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6advEpfCnjqSMVULVNQa
FNaPoVWHcEh8FJ8mE--/ECRYPTFS_FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6advEpfCnjq
SMVU7LmQnMhHfh0u5yByHsE6r---/ECRYPTFS_FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6a
dvEpfCnjqSMVUyFs1x3YH5TrEDJn4uOR7qk--/ECRYPTFS_FNEK_ENCRYPTED.FXbfg.wnsu2EnU
QFbyMTM6advEpfCnjqSMVU4ghdTluFURviDBNaKn5dqiV0xCDj5Ikg1JCyAoTTJN6-/ECRYPTFS_
FNEK_ENCRYPTED.FXbfg.wnsu2EnUQFbyMTM6advEpfCnjqSMVU-jycWae440W7yMwmiyP3Y2kL7
WCaoKGKU66C7Cxvk.c-/ECRYPTFS_FNEK_ENCRYPTED.FXbfg.wnsu2EnUQFbyMTM6advEpfCnjq
SMVUhi1aG2eEb2eWm.A0HVk-wDsIJHSIpRFFKCNvTGLuRog-/ECRYPTFS_FNEK_ENCRYPTED.FWb
fg.wnsu2EnUQFbyMTM6advEpfCnjqSMVUQSSHq93LQdjeusuoEfcYl---/ECRYPTFS_FNEK_ENCR
YPTED.FWbfg.wnsu2EnUQFbyMTM6advEpfCnjqSMVUtcq-q29SemW-IOdIxu-WME--/ECRYPTFS_
FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6advEpfCnjqSMVU8IbibKeFBd7fIPHPjbXAUU--/
ECRYPTFS_FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6advEpfCnjqSMVUIRoDoGSCaes2geXo
.1ofyE--/ECRYPTFS_FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6advEpfCnjqSMVUhJMdWTL
zJ5ZmOdxFdiH61E--/ECRYPTFS_FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6advEpfCnjqSM
VUa8r9YMTUfWQ4jQCNcJSCfE--/ECRYPTFS_FNEK_ENCRYPTED.FWbfg.wnsu2EnUQFbyMTM6adv
EpfCnjqSMVUX0etb6f3dEb6LYy1ZX6uFk--/ECRYPTFS_FNEK_ENCRYPTED.FXbfg.wnsu2EnUQF
byMTM6advEpfCnjqSMVUegHOnwkmJTzIaxaWQLEC-4bmxptKCfKKtzQ3vS4I4Mc-
(which is 1356 characters not including the mount point of the encrypted
drive)
This isn't a particularly crazy encrypted drive. It contains a few backups,
accounts, keys and so on. I'm not deliberately storing deep directory trees
or anything.
> > http://freebsd.1045724.n5.nabble.com/misc-184340-PATH-MAX-not-interope
> > rable-with-Linux-td5864469.html
>
> And examples where PATH_MAX is too low using Rsync ?
I've run into this when rsyncing Jenkins workspaces to FreeBSD (Jenkins
matrix builder generates long long paths). It isn't just rsync though, it
affects extracting tar archives on FreeBSD too.
Niall