Is there any approach out there which replaces this concept (probably
per mount) with something simpler, where files inherit permissions
from their containing directories by default?
Yeah, they're called default ACLs:
[root@ditirlns02 acl-test]# setfacl -m d:u:jadavis6:rwx --mask .
[root@ditirlns02 acl-test]# getfacl .
# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
[root@ditirlns02 acl-test]# mkdir subDir
[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# getfacl subDir/testFile
# file: subDir/testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# mkdir subDir/nestedDir
[root@ditirlns02 acl-test]# getfacl subDir/nestedDir
# file: subDir/nestedDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
Kind of a belabored example, but it illustrates that default ACL's inherit to subdirectories at creation time, and apply directly (as effective ACE's) to both directories and files. By design, changes in default ACL's won't actively descend down. Unix strives to be as inert as possible, so the expectation is the if you want new permissions to be applied to files that already exist then you'll do some setfacl
or chmod
magic to get it done. Changing automatically isn't even desirable. You would constantly be hearing about files that were accidentally left way too open or how the Admin didn't think about a particular directory nested underneath the changed directory that was used for an application that's now locked out, etc.
But an umask of 0777 has a risk of opening large holes in places not restricted in this fashion
Well this doesn't really relate to your first point, but POSIX ACL's take care of this too. ACL mask trumps the umask setting in a user's shell in terms of permissibility (actually they kind of work together, insofar as ACL mask will deny rights and umask just won't give them, leading to an implict deny). You can modify it with the setfacl
command:
[root@ditirlns02 acl-test]# setfacl -m m:r-x testFile
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx #effective:r-x
group::r-x
mask::r-x
other::r--
As you can see, even though the basic DAC on my personal account has me at "rwx" my account still only gets "r-x" because the ACL mask prevents that from happening. You can also manage default ACL masks the same way as other default ACL entries:
[root@ditirlns02 acl-test]# getfacl afterMask
# file: afterMask
# owner: root
# group: root
user::rwx
user:jadavis6:rwx #effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx #effective:r-x
default:group::r-x
default:mask::r-x
default:other::r-x
[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
I went back to the directory from before so you could see the "no automatic recalculation" in action.
Again this won't work if people start moving files around
I kind of got ahead of myself, so I've addressed why this isn't desirable behavior but I can elaborate. Basically, it's true that if you change the default ACL's you'll almost always want to change the ACL's for things that already exist. The problem lies in the fact that you can't design a system to properly anticipate what the permissions should be. If you did that, you would open yourself up to other security and stability concerns.
For instance:
You have a folder at /srv/applicationX/shares/accounting/deftManeuver
that holds proprietary information about your company's performance in various markets, only certain people should have access to it.
/srv/applicationX/shares is shared out over samba or NFS and is used company-wide.
A new department spins up, different group memberships require you to give them rwx on the shares directory.
The new department now has access to the proprietary information. and worse yet, you don't even realize that permissions are set up that way because it's been a year since you've had to do anything with deftManeuver
so you forgot it was even there.
That's kind of a drastic example, but it illustrates the problem. Leaving permissions inert, the platform can at least say "Well these permissions used to be acceptable, so maybe they're still pretty close to what they're trying to do." Whereas in the Windows world, you have permissions changing access controls on files you don't even know exist.
This way, you can set up the deftManeuver
once with the appropriate restrictions, and if you need to open it up, then the platform forcing you to explicitly tell it "I want xyz on directory abc and its descendants" the platform can at least hedge its bet against you not doing a recursive setfacl.
In my work life, I've been saved by this feature several times. I've opened a directory up too much to fix a problem, I've been told "hey hey hey, no don't do that" by the security people, and in the interim period, only new files had insecure permissions on them rather than the cumulative information built up over several years/decades.
EDIT (optional ACL rant):
This isn't to say that there aren't actual issues with POSIX ACL's, just that the objections listed here are either dealt with in-model or are features rather than defects.
The problem with regular POSIX ACL's is expressiveness. You still only get rwx but more operations should be targeted. Windows/NTFS takes a shotgun approach to permissions including stuff that doesn't make sense (like no native concept of a mask, a per-user delete permission instead of doing it the Unix way of saying "keeping a filename is pointless if it's an empty file so collapse it into 'write' or append permissions, etc) but include a lot of things that do make a lot of sense like having a right to append, a right to change permissions, a right to take ownership, etc.
There are also little things like not being able to set mask per-user or (better yet) per-group:
[root@ditirlns02 acl-test]# setfacl -m m:g:testGroup:rwx .
setfacl: Option -m: Invalid argument near character 3
[root@ditirlns02 acl-test]#
So there's no way to explicitly allow certain effective permissions to exceed the mask (what's good as a general rule is not always the case and this forces people to decide between lengthy work arounds between different users, or setting an overly permissive mask. Guess which route is usually taken...)
I honestly don't think anybody does permissions in a way that comprehensive, expressive and secure.
Best Answer
I found this example, titled: ACL and MASK in linux. In this article the following examples are demonstrated which I think help to understand how ACL's and
umask
interact with each other.Background
When a file is created on a Linux system the default permissions
0666
are applied whereas when a directory is created the default permissions0777
are applied.example 1 - file
Suppose we set our umask to 077 and touch a file. We can use
strace
to see what's actually happening when we do this:In this example we can see that the system call
open()
is made with the permissions 0666, however when theumask 077
is then applied by the kernel the following permissions are removed (---rwxrwx
) and we're left withrw-------
aka 0600.example - 2 directory
The same concept can be applied to directories, except that instead of the default permissions being 0666, they're 0777.
This time we're using the
mkdir
command. Themkdir
command then called the system callmkdir()
. In the above example we can see that themkdir
command called themkdir()
system call with the defaul permissions0777
(rwxrwxrwx
). This time with a umask of022
the following permissions are removed (----w--w-
), so we're left with 0755 (rwxr-xr-x
) when the directories created.example 3 (Applying default ACL)
Now let's create a directory and demonstrate what happens when the default ACL is applied to it along with a file inside it.
Now let's create the file,
aclfile
:Now get permissions of newly created file:
Notice the mask,
mask::rw-
. Why isn't itmask::rwx
just like when the directory was created?Check the
luvly
log file to see what default permissions were used for the file's creation:This is where it get's a little confusing. With the mask set to
rwx
when the directory was created, you'd expect the same behavior for the creation of the file, but it doesn't work that way. It's because the kernel is calling theopen()
function with the default permissions of0666
.To summarize
chmod
.References