Re: is setfacl broken? or is it Linux acl support in general?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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
[CentOS] [Kernel Development] [Red Hat Install] [PAM] [Fedora Users] [Red Hat Development] [Red Hat 9] [Big List of Linux Books] [Linux Admin] [Photo Sharing] [Hot Springs] [Gimp] [Asterisk PBX] [Yosemite News] [Red Hat Crash Utility]