Score:0

On CentOS 6, how to let user-created files inherit permissions from their parent directory?

bh flag

So our servers are set-up like this:
Folder structure

/asic is our grand project's folder, /200T is a subproject of that grand project, and folders right under /200T such as /lbh are each worker's personal directories who are working on the subproject. /asic, /200T, /lbh were all created by root and then had their properties reconfigured by root via chmod -R and chown -R. /asic and /200T are owned by root and belongs to groups asic and 200T respectively, while /lbh is owned by the worker's user account lbh and belongs to group asic.

The idea is that content within /asic and /200T can be seen by all personell working on asic and 200T yet they cannot have write access to these 2 directories-- if they want to create something, they'll have to do that within their own directories (/lbh and the like). When a worker creates something in their own directory, we want other workers of the same sub-project to be able to read that new thing, but not modify it by accident. For example, lbh just created a file testbench.v and a folder /results under /asic/200T/lbh. Another person (glj) on the 200T subproject should be able to read /asic/200T/lbh/testbench.v and /asic/200T/lbh/results but not write into them. If glj wants to modify them, he'll have to copy them to his own directory /asic/200T/glj and then do so.

To achieve the goals above, we need the permissions of directories created by lbh to be drwxr-s--- and files to be rwxr-s--- by default, however the reality looks like this:
Files and folders created by lbh and root

Resulting in each worker being able to write into everyone's own folders and files, which is exactly what we're trying to avoid. The umask of root is 0022, and the umask of normal users is 0002.

My questions:

  1. Why are the files created by users (like /lbh) under their personal directories (like lbh) ignoring the drwxr-s--- permission of the personal folder and defaulting to (d)rwxrwsr-x?
  2. Is there safe method to let workers create files and folders with (d)rwxr-s--- by default? Asking every user to manually chmod everything every time is too much of a hassle, and I'm worried that changing the default umask value can lead to new surprise issues down the line.

Thanks a lot!


Edit: The folder structure and permission of files created by lbh and root look like this:

[lbh@<machine> lbh]$ ls -al
total 16
drwxr-s---. 4 lbh  200T 4096 Oct  1 02:40 .
drwxr-sr-x. 4 root 200T 4096 Oct  1 02:18 ..
drwxrwsr-x. 2 lbh  200T 4096 Oct  1 02:26 aaa_lbh
drwxr-sr-x. 2 root 200T 4096 Oct  1 02:26 aaa_root
-rw-rw-r--. 1 lbh  200T    0 Oct  1 02:38 file_lbh.txt
-rw-r--r--. 1 root 200T    0 Oct  1 02:40 file_root.txt
[lbh@<machine> lbh]$ pwd
/asic/200T/lbh
[lbh@<machine> lbh]$ cd ..
[lbh@<machine> 200T]$ ls -al
total 16
drwxr-sr-x. 4 root 200T 4096 Oct  1 02:18 .
drwxr-x---. 3 root asic 4096 Oct  1 02:16 ..
drwxr-sr-x. 2 root 200T 4096 Oct  1 02:18 aaa
drwxr-s---. 4 lbh  200T 4096 Oct  1 02:40 lbh
[lbh@<machine> 200T]$ pwd
/asic/200T
[lbh@<machine> 200T]$ 

And getfaclresults of directories and files are as follows:

[lbh@<machine> Desktop]$ getfacl /asic
getfacl: Removing leading '/' from absolute path names
# file: asic
# owner: root
# group: asic
user::rwx
group::r-x
other::---

[lbh@<machine> Desktop]$ getfacl /asic/200T/
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/
# owner: root
# group: 200T
# flags: -s-
user::rwx
group::r-x
other::r-x

[lbh@<machine> Desktop]$ getfacl /asic/200T/lbh
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh
# owner: lbh
# group: 200T
# flags: -s-
user::rwx
group::r-x
other::---

[lbh@<machine> Desktop]$ getfacl /asic/200T/lbh/aaa_lbh/
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh/aaa_lbh/
# owner: lbh
# group: 200T
# flags: -s-
user::rwx
group::rwx
other::r-x

[lbh@<machine> Desktop]$ getfacl /asic/200T/lbh/aaa_root/
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh/aaa_root/
# owner: root
# group: 200T
# flags: -s-
user::rwx
group::r-x
other::r-x

[lbh@<machine> Desktop]$ getfacl /asic/200T/lbh/file_lbh.txt 
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh/file_lbh.txt
# owner: lbh
# group: 200T
user::rw-
group::rw-
other::r--

[lbh@<machine> Desktop]$ getfacl /asic/200T/lbh/file_root.txt 
getfacl: Removing leading '/' from absolute path names
# file: asic/200T/lbh/file_root.txt
# owner: root
# group: 200T
user::rw-
group::r--
other::r--

[lbh@<machine> Desktop]$ touch hello.txt
[lbh@<machine> Desktop]$ mkdir hi 
[lbh@<machine> Desktop]$ ls -al
total 12
drwxr-xr-x.  3 lbh lbh 4096 Oct  9 17:28 .
drwx------. 36 lbh lbh 4096 Oct  9 17:21 ..
-rw-rw-r--.  1 lbh lbh    0 Oct  9 17:27 hello.txt
drwxrwxr-x.  2 lbh lbh 4096 Oct  9 17:28 hi
[lbh@<machine> Desktop]$ getfacl hi
# file: hi
# owner: lbh
# group: lbh
user::rwx
group::rwx
other::r-x

[lbh@<machine> Desktop]$ getfacl hello.txt 
# file: hello.txt
# owner: lbh
# group: lbh
user::rw-
group::rw-
other::r--

[lbh@<machine> Desktop]$ 
Score:0
za flag

Linux doesn't support permission inheritance, so you can't do what you asked in the question topic.

The best you can do is to set default POSIX ACL which will apply to all newly created files and directories. This is not the inheritance, just the default:

setfacl -m default:user:<username>:rwx <dir>
setfacl -m default:group:<groupname>:rwx <dir>

After this, if anybody creates a file or directory in (if they are allowed to create objects there, of course), that object will get additional ACL user:<username>:rwx and group:<groupname>:rwx. You can set default permissions for owner and group-owner by setting <username> and <groupname> blank.

This "default" could only be set upon a directory, because there is no point to apply this to files. Permissions set this way also get masked with umasks, so if some bit is dropped in umask, this bit will be dropped from a permission. For instance, when you create a file, if you don't give it executable bit, it wouldn't be made executable (as expected). Created subdirectories will also have the same "default" ACLs set, so its descendants will have these ACLs set too. You have to remove or change ACLs on subdirectories after creation to stop this propagation.

Check the ACL with getfacl <dir>. Of course, there could be several such defaults (and it seems you have to end up with several rules); at least, requirements that I encountered always mandated the presence of at least two default group ACLs).


You can not set "default file owners" this way, the owner will always be set to creating process effective uid. By default, group-owner will be set to process gid, but you can change that by using the setgid bit on the parent directory:

    chmod g+s <dir>

after that, any object created in that directory will copy its group-owner by default, even if creating user doesn't belong to that group. This setgit bit propagates to subdirectories.

Owners can set group-owner to any group that they belong to. If they don't belong to the group derived by setgid, they can change their file group-owner to any group they belong to, but after that they won't be able to change it back into setgid value.


I want to note again explicitely, this is not an inheritance, this is setting defaults which is not exactly the same. If you change something on parent object afterwards, already created objects will always retain their permissions in Linux.

While, for example, in Windows, when you set sub-object ACLs to "inherit", changing parent ACLs will affect descendants, which is the proper inheritance.

NoobAdmin avatar
bh flag
Thanks a lot! I'll try to see if this method works well enough for us. Though I'm still confused about why user-created folders are drwxrwsr-x? A umask value of 0022 should make it drwxrwxr-x, right? So is the gid bit inherited?
NoobAdmin avatar
bh flag
Correction: sorry I meant a umask value of 0002 (normal user), not 0022 (root)
Nikita Kipriyanov avatar
za flag
*nothing* is inherited. Default ACLs are saved as ACL, umask is set as file modes, and then if somebody accesses the file Linux reads both and ANDs them calculate actual permission.
NoobAdmin avatar
bh flag
So in my second screenshot ("Files and folders created by lbh and root") the folder "aaa_lbh" created by lbh is drwxrwsr-x instead of drwxrwxr-x, and that "s" is there because Linux calculated both lbh's umask and the parent folder's (/asic/200T/lbh) ACL?
Nikita Kipriyanov avatar
za flag
Doesn't "s" mean "setgid"? It doesn't have anything in common with these masks. But I must admit I forgot about this possibility. It allows descendants to derive owner-group from the directory instead of process gid. If you want to explore ACLs, use `getfacl`, it also caclulates effective permissions. And, finally, all of this is *textual* information, please, don't take screenshots, copy and paste the console output instead.
NoobAdmin avatar
bh flag
Thanks, I just updated my original post with terminal outputs. New files created by ```lbh``` on ```Desktop``` do not have the ```setgid``` bit, so it seems new files created under ```/asic/200T/lbh``` do have the ```s``` flag because the parent directory does.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.