From nobody@FreeBSD.org  Thu Jan  3 15:38:38 2013
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1])
	by hub.freebsd.org (Postfix) with ESMTP id A26F4EEE
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  3 Jan 2013 15:38:38 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 93790F47
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  3 Jan 2013 15:38:38 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r03FccIO007034
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 3 Jan 2013 15:38:38 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.5/8.14.5/Submit) id r03FccYc007033;
	Thu, 3 Jan 2013 15:38:38 GMT
	(envelope-from nobody)
Message-Id: <201301031538.r03FccYc007033@red.freebsd.org>
Date: Thu, 3 Jan 2013 15:38:38 GMT
From: Sandra <littlesandra88@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: owner@ always have ZFS ACL full permissions. Should not be the case.
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         174948
>Category:       kern
>Synopsis:       [zfs] owner@ always have ZFS ACL full permissions. Should not be the case.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    trasz
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 03 15:40:01 UTC 2013
>Closed-Date:    Tue Jun 25 08:33:29 UTC 2013
>Last-Modified:  Tue Jun 25 08:33:29 UTC 2013
>Originator:     Sandra
>Release:        9
>Organization:
>Environment:
>Description:
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
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Jan 7 03:59:39 UTC 2013 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=174948 
Responsible-Changed-From-To: freebsd-fs->trasz 
Responsible-Changed-By: trasz 
Responsible-Changed-When: Tue Jan 15 16:56:43 UTC 2013 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=174948 
State-Changed-From-To: open->feedback 
State-Changed-By: trasz 
State-Changed-When: Mon Apr 1 13:17:28 UTC 2013 
State-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=174948 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/174948: commit references a PR
Date: Mon,  1 Apr 2013 13:17:36 +0000 (UTC)

 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"
 

From: Sandra Schlichting <littlesandra88@gmail.com>
To: bug-followup@freebsd.org, littlesandra88@gmail.com
Cc:  
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

 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.

From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org>
To: Sandra Schlichting <littlesandra88@gmail.com>,
 bug-followup@freebsd.org
Cc:  
Subject: Re: kern/174948: [zfs] owner@ always have ZFS ACL full permissions. Should not be the case.
Date: Sat, 6 Apr 2013 21:15:46 +0200

 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?
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/174948: commit references a PR
Date: Mon,  8 Apr 2013 12:10:11 +0000 (UTC)

 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 
State-Changed-By: trasz 
State-Changed-When: Tue Jun 25 08:33:27 UTC 2013 
State-Changed-Why:  
Not a bug, but I improved the documentation somewhat. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=174948 
>Unformatted:
