is setfacl broken? or is it Linux acl support in general?

[Cameron Simpson]

On 30Aug2011 01:59, Furnish, Trever G <TGFurnish at herffjones.com> wrote:
| Can someone help me understand where I'm going wrong with setfacl?

Nothing is. It is probably behaving as documented:-)

| I want every new file created in a directory to have an effective acl of rwx for user "bob".
| I do this:
| setfacl -m d:u:bob:rwx,u:bob:rwx directory
| 
| Then I touch a new file into that directory:
| touch directory/newfile
| 
| Unfortunately, newfile comes in with some seemingly random acl -- sometimes it's r--, sometimes it's rw-, but it's never rwx.
| 
| What gives?
| 
| I've tried explicitly setting the default and non-default masks too -- that doesn't seem to help (but here's the command I mean):
| setfacl -m d:m::rwx,m::rwx,d:u:bob:rwx,u:bob:rwx .
| 
| Still gives the same results.
| 
| If I then turn around and re-apply what should be the existing default acl to the new file, this time it sticks.  Same thing happens if I 'chmod +x newfile':
| setfacl -m u:bob:rwx newfile
| 
| It really just seems like default acl support under Linux doesn't work.  That really, really sucks.

As Barry mentioned, the default ACL applied is subject to the file
creation mode setting. If you look at "man 5 acl", it says:

  OBJECT CREATION AND DEFAULT ACLs
     The access ACL of a file object is initialized when the object is
     created with any of the creat(), mkdir(), mknod(), mkfifo(), or open()
     functions.  If a default ACL is associated with a directory, the mode
     parameter to the functions creating file objects and the default ACL of
     the directory are used to determine the ACL of the new object:

     1.   The new object inherits the default ACL of the containing directory
          as its access ACL.

     2.   The access ACL entries corresponding to the file permission bits
          are modified so that they contain no permissions that are not
          contained in the permissions specified by the mode parameter.

So your "rwx" in the _default_ ACL is still subject to the file creation
mode bits.

Now, normally when you create a file the open() system call looks like
this:

  open(your_filename, 0666)

This indicates rw-rw-rw- permissions, which are then modified by the
umask setting; a umask of 027 would cause the resulting permissions to
be rw-r-----.

The important thing here is that unless the file is the output of a
compiler (eg the cc or gcc commands) then the mode setting in the open()
call DOES NOT normally include any execute bits. This is a deliberate
design decision; random files should not be executable by default - this
avoids risk of accidentally executing random data files.

So when you "touch" a file, the resulting item will never have execute
permission untill you add it later yourself.

This is correct behaviour.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

"... cunning as a sewer rat."   - Karen, about me