On 30Aug2011 01:59, Furnish, Trever G <TGFurnish@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> DoD#743
http://www.cskk.ezoshosting.com/cs/
"... cunning as a sewer rat." - Karen, about me
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
