zfs aclmode/aclinherit, setfacl, chmod, the man page and reality

Harald Schmalzbauer h.schmalzbauer at omnilan.de
Mon Jul 14 09:45:08 UTC 2014


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>


More information about the freebsd-stable mailing list