The Oracle ZFS specs says http://docs.oracle.com/cd/E19253-01/819-5461/ftyxi/index.html "The owner of a file is granted the write_acl permission unconditionally, even if the permission is explicitly denied." But it is not possible to restrict the owner in any way. The following is the output from the script in "How to repeat the problem", which shows that removing all ACL's on owner@ have no effect. p="/tank/project1" f="$p/test2" u="user1" rm -f $f setfacl -b $p setfacl -m group@::fd:allow $p || exit 1 setfacl -m everyone@::fd:allow $p || exit 1 setfacl -m owner@::fd:allow $p || exit 1 setfacl -m u:$u:rwx:fd:allow $p || exit 1 setfacl -m u:$u:aA:fd:deny $p || exit 1 getfacl $p # file: /tank/project1 # owner: root # group: wheel user:user1:------aA------:fd----:deny user:user1:rwx-----------:fd----:allow owner@:--------------:fd----:allow group@:--------------:fd----:allow everyone@:--------------:fd----:allow su -m $u -c "echo test > $f" setfacl -m u:$u::allow $f || exit 1 getfacl $f # file: /tank/project1/test2 # owner: user1 # group: wheel user:user1:------aA------:------:deny user:user1:--------------:------:allow owner@:--------------:------:allow group@:--------------:------:allow everyone@:--------------:------:allow su -m $u -c "touch -amct 191212121212 $f" ls -l $f ----------+ 1 user1 wheel 5 Dec 12 1912 /tank/project1/test2 su -m $u -c "cat $f" cat: /tank/project1/test2: Permission denied su -m $u -c "chmod 777 $f" ls -l $f -rwxrwxrwx+ 1 user1 wheel 5 Dec 12 1912 /tank/project1/test2 su -m $u -c "cat $f" test su -m $u -c "setfacl -m u:$u:full_set:allow $f" su -m $u -c "setfacl -x u:$u::deny $f" getfacl $f # file: /tank/project1/test2 # owner: user1 # group: wheel user:user1:rwxpDdaARWcCos:------:allow owner@:rwxp--aARWcCos:------:allow group@:rwxp--a-R-c--s:------:allow everyone@:rwxp--a-R-c--s:------:allow How-To-Repeat: p="/tank/project1" f="$p/test2" u="user1" rm -f $f setfacl -b $p setfacl -m group@::fd:allow $p || exit 1 setfacl -m everyone@::fd:allow $p || exit 1 setfacl -m owner@::fd:allow $p || exit 1 setfacl -m u:$u:rwx:fd:allow $p || exit 1 setfacl -m u:$u:aA:fd:deny $p || exit 1 getfacl $p su -m $u -c "echo test > $f" setfacl -m u:$u::allow $f || exit 1 getfacl $f su -m $u -c "touch -amct 191212121212 $f" ls -l $f su -m $u -c "cat $f" su -m $u -c "chmod 777 $f" ls -l $f su -m $u -c "cat $f" su -m $u -c "setfacl -m u:$u:full_set:allow $f" su -m $u -c "setfacl -x u:$u::deny $f" getfacl $f
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Responsible Changed From-To: freebsd-fs->trasz I'll take it.
State Changed From-To: open->feedback Could you clarify which part of the script shows the problem? In your example, cat ('read_data') is properly denied, while touch ('write_attributes') , , setfacl ('write_acl') and chmod ('write_acl') are always permitted for the file owner. I'll update the manual page to make it clear.
Author: trasz Date: Mon Apr 1 13:17:28 2013 New Revision: 248972 URL: http://svnweb.freebsd.org/changeset/base/248972 Log: Mention that read_attributes, write_attributes, read_acl and write_acl are always permitted for the file owner. PR: kern/174948 MFC after: 1 week Modified: head/bin/setfacl/setfacl.1 Modified: head/bin/setfacl/setfacl.1 ============================================================================== --- head/bin/setfacl/setfacl.1 Mon Apr 1 11:28:52 2013 (r248971) +++ head/bin/setfacl/setfacl.1 Mon Apr 1 13:17:28 2013 (r248972) @@ -26,7 +26,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 8, 2013 +.Dd April 1, 2013 .Dt SETFACL 1 .Os .Sh NAME @@ -401,6 +401,10 @@ NFSv4 ACL entries are evaluated in their .Pp Multiple ACL entries specified on the command line are separated by commas. +.Pp +Note that the file owner is always granted the read_acl, write_acl, +read_attributes, and write_attributes permissions, even if the ACL +would deny it. .Sh EXIT STATUS .Ex -std .Sh EXAMPLES _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
The problem is, as I see it, that root removes all ACL's for user1 on file1. When user1 tries to read file1, he gets permission denied. That is perfect. To get around this, user1 just chmod 777 file1, and he can read the file. Security bug I would say. Also user1 can also set full ACL permissions on file1. Also a security issue I should say. When you say that the owner can not be restricted for read_attributes, write_attributes, read_acl and write_acl, then owner should be able to be denied read, right? It would be very useful to be able to deny owner read access, so you can have a daemon that only is allowed to append data to a file, so even is the daemon is compromised, the attacker can't read the log file that the daemon have been appending to. I.e. the attacker can't modify or delete the log file to hide the attack.
Wiadomo=B6=E6 napisana przez Sandra Schlichting w dniu 3 kwi 2013, o = godz. 16:20: > The following reply was made to PR kern/174948; it has been noted by = GNATS. >=20 > From: Sandra Schlichting <littlesandra88@gmail.com> > To: bug-followup@freebsd.org, littlesandra88@gmail.com > Cc: =20 > Subject: Re: kern/174948: [zfs] owner@ always have ZFS ACL full = permissions. > Should not be the case. > Date: Wed, 3 Apr 2013 16:18:46 +0200 >=20 > The problem is, as I see it, that root removes all ACL's for user1 on > file1. When user1 tries to read file1, he gets permission denied. That > is perfect. >=20 > To get around this, user1 just chmod 777 file1, and he can read the > file. Security bug I would say. Unix permissions always worked that way - the file owner can always = "manage" her own files. If you want to prevent it, change the file ownership. > Also user1 can also set full ACL permissions on file1. Also a security > issue I should say. >=20 > When you say that the owner can not be restricted for read_attributes, > write_attributes, read_acl and write_acl, then owner should be able to > be denied read, right? Of course. But that seems to work. The fact that the owner can grant herself the permission to read is orthogonal to that and, again, that's how Unix permissions have always worked. > It would be very useful to be able to deny owner read access, so you > can have a daemon that only is allowed to append data to a file, so > even is the daemon is compromised, the attacker can't read the log > file that the daemon have been appending to. I.e. the attacker can't > modify or delete the log file to hide the attack. And you can do that - just make sure the files are not owned by that daemon. Or use "sappend" flag (man chflags). --=20 If you cut off my head, what would I say? Me and my head, or me and my = body?
Author: trasz Date: Mon Apr 8 12:09:53 2013 New Revision: 249254 URL: http://svnweb.freebsd.org/changeset/base/249254 Log: MFC r248972: Mention that read_attributes, write_attributes, read_acl and write_acl are always permitted for the file owner. PR: kern/174948 Modified: stable/9/bin/setfacl/setfacl.1 Directory Properties: stable/9/bin/setfacl/ (props changed) Modified: stable/9/bin/setfacl/setfacl.1 ============================================================================== --- stable/9/bin/setfacl/setfacl.1 Mon Apr 8 10:53:22 2013 (r249253) +++ stable/9/bin/setfacl/setfacl.1 Mon Apr 8 12:09:53 2013 (r249254) @@ -26,7 +26,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 8, 2013 +.Dd April 1, 2013 .Dt SETFACL 1 .Os .Sh NAME @@ -401,6 +401,10 @@ NFSv4 ACL entries are evaluated in their .Pp Multiple ACL entries specified on the command line are separated by commas. +.Pp +Note that the file owner is always granted the read_acl, write_acl, +read_attributes, and write_attributes permissions, even if the ACL +would deny it. .Sh EXIT STATUS .Ex -std .Sh EXAMPLES _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
State Changed From-To: feedback->closed Not a bug, but I improved the documentation somewhat.