Date: Mon, 14 Jul 2014 09:40:11 +0200 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: zfs aclmode/aclinherit, setfacl, chmod, the man page and reality Message-ID: <53C3895B.2000601@omnilan.de>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA813324B23C5131D1CA327FB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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=3Dpassthrough-x on the corresponding filesystem.
1) Odd behaviour with aclmode=3Dgroupmask
=46rom 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=3Dpassthrough!
So that at the moment, as soon as I use ZFS ACLs, I have to use
aclmode=3Drestricted. But that leads to other problems, e.g. vi swap
files. A directory will fill up with undeleted swap files=E2=80=A6
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=3Drestricted
=46rom 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=3Drestricted):
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=E2=
=80=A6
But that's another story.
What are the results for aclmode / aclinherit tests on other FreeBSD
versions?
Thanks,
-Harry
--------------enigA813324B23C5131D1CA327FB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAlPDiVsACgkQLDqVQ9VXb8gcpwCghvR/TUIBVfd4R13n3FdgGJ2v
VDcAnj2V5MoAfoUjRBI5woso/YVpkAho
=QYBB
-----END PGP SIGNATURE-----
--------------enigA813324B23C5131D1CA327FB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53C3895B.2000601>