linux/setfacl - Set all current/future files/directories in parent directory to 775 with specified owner/group
I actually found something that so far does what I asked for, sharing here so anyone who runs into this issue can try out this solution:
sudo setfacl -Rdm g:groupnamehere:rwx /base/path/members/
sudo setfacl -Rm g:groupnamehere:rwx /base/path/members/
R is recursive, which means everything under that directory will have the rule applied to it.
d is default, which means for all future items created under that directory, have these rules apply by default.
m is needed to add/modify rules.
The first command, is for new items (hence the d), the second command, is for old/existing items under the folder. Hope this helps someone out as this stuff is a bit complicated and not very intuitive.
To go with your accepted answer ...
You can combine those commands together as:
sudo setfacl -Rm d:g:groupnamehere:rwx,g:groupnamehere:rwx /base/path/members/
setfacl on linux has the -d
and -k
options for manipulating default permissions which are probably what you are looking for (see man for more info).
It is easy to recursively set simple UNIX permissions at upon demand of an appropriately authorized user, the permissions of directories and files. It is not possible to automatically impose this.
You could tell users to use the set the umask of 0002, and that helps to make new files at 0775 (depending on the application). But it is not enforcable.
My understanding is that ACLs are not inherited on UNIX/Linux systems. They are set upon demand.
As for file/directory ownership, you are pretty much out of luck here.
As for file/directory group ownership, by setting the directory set-gid bit (i.e. g+s on DIRECTORIES), this does cause the group ownership to be inherited.
What I have done in such situations is to execute a periodic root cron script which resets non-conforming permissions/ownerships to the standard in such directories.
Another (NOT RECOMMENDED) process is to have the same user-id be used when working on these files. This could be accomplished by the user logging into the system under his own UID, and then using sudo or su to run as the id. This still is not 100% especially concerning ACLs and permission bits.