Harald Schmalzbauer
2014-Jul-14 07:40 UTC
zfs aclmode/aclinherit, setfacl, chmod, the man page and reality
Dear all,
I see some really odd things regarding zfs ACLs on FreeBSD-9.2 and 9.3.
For the first example (and all real-world setups), I have
aclinherit=passthrough-x on the corresponding filesystem.
1) Odd behaviour with aclmode=groupmask
From zfs(8):
An aclmode property of groupmask reduces permissions granted in all
ALLOW entries found in the ACL such that they are no greater than the
group permissions specified by chmod(2).
Why does chmod destroy the DENY ACE???
Example:
getfacl netshares/
# file: netshares/
# owner: root
# group: bin
owner@:rwxp--aARWcCos:------:allow
group@:r-x---a-R-c--s:------:allow
everyone@:------a-R-c--s:------:allow
:
setfacl -a 2 everyone@:D:d:deny netshares/
After adding deny ACE, getfacl shows:
owner@:rwxp--aARWcCos:------:allow
group@:r-x---a-R-c--s:------:allow
everyone@:----D---------:-d----:deny
everyone@:------a-R-c--s:------:allow
:
chmod g+w netshares/
After granting write acces for groups, getfacl shows:
owner@:rwxp--aARWcCos:------:allow
group@:rwxp--a-R-c--s:------:allow
everyone@:------a-R-c--s:------:allow
Hard to imagin anybody on earth would want/expect/tolerate such a
result. Same result if aclmode=passthrough!
So that at the moment, as soon as I use ZFS ACLs, I have to use
aclmode=restricted. But that leads to other problems, e.g. vi swap
files. A directory will fill up with undeleted swap files?
If at least there was a way to set aclmode for directories different
than for files. In that case, chmod(2) was allowed to destroy ACLs of
files, but directorys were protected. In many real-world setups, that
would suffice.
2) Odd behaviour with aclinherit=restricted
From zfs(8):
The property value restricted (the default) removes the write_acl and
write_owner permissions when the ACL entry is inherited.
Example (with aclinherit=restricted):
getfacl netshares/
# file: netshares/
# owner: root
# group: wheel
owner@:rwxp--aARWcCos:fd----:allow
group@:rwxp--a-R-c--s:fd----:allow
everyone@:------a-R-c--s:fd----:allow
:
netshares/testdir
After creating testdir, I'd expect to have everyone without read-bit,
like above set up. Here's the real result:
owner@:rwxp--aARWcCos:------:allow
group@:rwxp--a-R-c--s:------:allow
everyone@:r-x---a-R-c--s:------:allow
umask was in use, not directory inheritance!
If I set aclinherit to passthrough-x, inheritance works as designed, but
why doesn't it work with the default restricted aclinherit property?
I don't have any Solaris handy to compare results, but clearly here's
something really wrong. Either the man page is wrong, or zfs acl
handling does things wrong.
For many simple real-world file-system access restrictions, ACLs were
avoidable if we had a stick-bit-inheritance for trivial permission mode?
But that's another story.
What are the results for aclmode / aclinherit tests on other FreeBSD
versions?
Thanks,
-Harry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140714/ab710458/attachment.sig>
Harald Schmalzbauer
2014-Jul-14 09:45 UTC
zfs aclmode/aclinherit, setfacl, chmod, the man page and reality
Bez?glich Harald Schmalzbauer's Nachricht vom 14.07.2014 09:40 (localtime):> Dear all, > > I see some really odd things regarding zfs ACLs on FreeBSD-9.2 and 9.3. > > For the first example (and all real-world setups), I have > aclinherit=passthrough-x on the corresponding filesystem. > > 1) Odd behaviour with aclmode=groupmask > From zfs(8): > An aclmode property of groupmask reduces permissions granted in all > ALLOW entries found in the ACL such that they are no greater than the > group permissions specified by chmod(2). > > Why does chmod destroy the DENY ACE??? > > Example: > getfacl netshares/ > # file: netshares/ > # owner: root > # group: bin > owner@:rwxp--aARWcCos:------:allow > group@:r-x---a-R-c--s:------:allow > everyone@:------a-R-c--s:------:allow > : > setfacl -a 2 everyone@:D:d:deny netshares/ > After adding deny ACE, getfacl shows: > owner@:rwxp--aARWcCos:------:allow > group@:r-x---a-R-c--s:------:allow > everyone@:----D---------:-d----:deny > everyone@:------a-R-c--s:------:allow > : > chmod g+w netshares/ > After granting write acces for groups, getfacl shows: > owner@:rwxp--aARWcCos:------:allow > group@:rwxp--a-R-c--s:------:allow > everyone@:------a-R-c--s:------:allow > > Hard to imagin anybody on earth would want/expect/tolerate such a > result. Same result if aclmode=passthrough! > So that at the moment, as soon as I use ZFS ACLs, I have to use > aclmode=restricted. But that leads to other problems, e.g. vi swap > files. A directory will fill up with undeleted swap files? > > If at least there was a way to set aclmode for directories different > than for files. In that case, chmod(2) was allowed to destroy ACLs of > files, but directorys were protected. In many real-world setups, that > would suffice. > > > > > 2) Odd behaviour with aclinherit=restricted > From zfs(8): > The property value restricted (the default) removes the write_acl and > write_owner permissions when the ACL entry is inherited. > > Example (with aclinherit=restricted): > getfacl netshares/ > # file: netshares/ > # owner: root > # group: wheel > owner@:rwxp--aARWcCos:fd----:allow > group@:rwxp--a-R-c--s:fd----:allow > everyone@:------a-R-c--s:fd----:allow > : > netshares/testdir > After creating testdir, I'd expect to have everyone without read-bit, > like above set up. Here's the real result: > owner@:rwxp--aARWcCos:------:allow > group@:rwxp--a-R-c--s:------:allow > everyone@:r-x---a-R-c--s:------:allow > > umask was in use, not directory inheritance! > If I set aclinherit to passthrough-x, inheritance works as designed, but > why doesn't it work with the default restricted aclinherit property? > > I don't have any Solaris handy to compare results, but clearly here's > something really wrong. Either the man page is wrong, or zfs acl > handling does things wrong. > > For many simple real-world file-system access restrictions, ACLs were > avoidable if we had a stick-bit-inheritance for trivial permission mode? > But that's another story. > > What are the results for aclmode / aclinherit tests on other FreeBSD > versions?I tried OpenIndiana ? same results. With aclinherit=restricted, ACE everyone@:----D---------:-d----:deny wasn't inherited by subdir, even dir_inherit bit was set. With aclmode=groupmask, ACE was destroyed with chmod o+wx. It seems by design, once ACLs are used, chmod mustn't be used in traditional way (at all in case for FreeBSD). So by default, IMHO aclmode should be restricted, not discard!. Or am I missing something?!? I don't really get the idea why chmod even on OpenIndiana has so fatal consequences with ZFS-ACLs. So back to real-world problem: To emulate sticky-bit with ACLs (which can be inherited), I usually do this: setfacl -b netshares/ chmod 770 netshares/ setfacl -a 2 everyone@:D:d:deny netshares/ setfacl -m owner@:rwxp-daARWcCos:fd:allow netshares/ setfacl -m group@:rwxp--a-R-c--s:fd:allow netshares/ setfacl -m everyone@:------a-R-c--s:fd:allow netshares/ resulting in: # file: netshares/ # owner: root # group: wheel owner@:rwxp-daARWcCos:fd----:allow group@:rwxp--a-R-c--s:fd----:allow everyone@:----D---------:-d----:deny everyone@:------a-R-c--s:fd----:allow Now group can add/write files in this directory, but only owner can delete his files ? almost identical to what sticky bit allows. Now I need to set zfs property aclmode=restricted, otherwise any chmod command would destroy my intended delete-protection. But now e. g. vim can't be used with default swap directory config, becase it tries to chmod swap file, get's error back and doesn't remove it afterwards; not to mention the annoying false warning. What about making 'setfacl -b netshares' defaulting for owner@ to rwxp-daARWcCos instead of rwxp--aARWcCos? That would mean I don't have to set the file_inherit bit and ACL is like trivial-ACL, so chmod does work with aclmode=restricted in some cases (if no other ACEs are inherited). At least, we could have the sticky bit emulated. Thanks for any hints. -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140714/aaa0a8ad/attachment.sig>