Date: Thu, 9 Aug 2001 14:36:20 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: "Daniel J. Mastrian" <djm2@andrew.cmu.edu>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Default ACL execute permission inheritance
Message-ID: <20010809143620.M78571@boing.melbourne.sgi.com>
References: <788335771.997220748@[192.168.1.4]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <788335771.997220748@[192.168.1.4]>; from djm2@andrew.cmu.edu on Tue, Aug 07, 2001 at 09:45:48PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Dan,

On Tue, Aug 07, 2001 at 09:45:48PM -0400, Daniel J. Mastrian wrote:
> I've searched through the Linux-XFS mailing list archives, searched through 
> google, and even skimmed the IEEE Posix 1003.1e draft standard, and perhaps 
> I'm just dense, but I haven't found a sufficient answer to this question 
> about ACLs (in general...although in this case I am using XFS on Linux)
> 
> I want the user and group who owns /foo to have rw- for all files, and rwx 
> for all directories.  I want user apache to have r-- for all files, and r-x 
> for all directories.  Everyone else should have --- (although I want to 
> leave the option open to give a specific user write access later on, for 
> example)
> 
> So say I set /foo to have this default ACL... 
> u::rwx,g::rwx,o::---,m::rwx,u:apache:r-x
> 
> Now, if I create a directory /foo/bar, bar has an access ACL and a default 
> ACL identical to /foo's default ACL.  Correct, intended behavior, yay.
> 
> However, if I 'touch somefile', I get a file access ACL that is not what I 
> expected...
> 
>   u::rw-,g::rwx,o::---,m::rw-,u:apache:r-x
> 
> I see two things wrong with this.  (1) ACL_GROUP_OBJ has rwx perms.  It 
> should not be able to execute.  I believe someone else on this list 
> mentioned that this was part of the standard, although weird.  If this is 
> intended behavior, could someone please confirm it?  (2) apache has r-x 
> perms, and should also not have the execute bit set.  Shouldn't the execute 
> bit have been dropped by intersection with the rw-rw-rw- creation 
> permissions?
> 
The result you reported seems correct to me according to the standard.

* As you would probably know, the umask takes no effect
  in this situation with a default ACL.
  (just thought I'd mention it :)
* The mode bits of the creat/open called by touch (rw-rw-rw-)
  are intersected with:
    USER_OBJ ACE perms. - with the mode's user permissions
    OTHER ACE perms. - with the mode's other permissions
    GROUP_OBJ ACE perms. if there is no MASK ACE 
                     - with the mode's group permissions
  or
    MASK ACE if there is one - with the mode's group permissions
  Check out section 5.3.1.2 of standard - confusingly worded.
  Note that if there is a MASK ACE, then the standard group permissions
  (as seen with ls -l) will match the MASK ACE 
  (see section 23.1.2 of standard on File Permission bits).
* Thus, USER and GROUP ACEs are the same as the default ACLs';
  they are not intersected with anything.
  HOWEVER, the MASK ACE will be used with them in the ACL Access Check
  algorithm (section 23.1.5 of standard).
* In your case, as we have a MASK ACE, the GROUP_OBJ permissions
  are not intersected with the mode's group permissions,
  the MASK ACE's permissions are set instead (as I said above)

Cheers,
Tim.