4

I often find that the unix way of handling file permissions is powerful, particularly when combined with ACLs, but rather difficult to handle. Setting file modes, group ownership and extended attributes correctly for every created file can quickly become tedious.

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?

I know this would probably violate a number of POSIX expectations, but on the other hand, thungs like quiet vfat mouts already disregard mode and several permission changes, so that shouldn't prevent new ideas from being developed.

To give an example, I'm looking for something where I can be sure that as long as a user drops his file inside a certain directory, it will be writable and deletable by a given group, and readable only by the rest of the world, no matter the user's umask and current group.

Reasons why what I know so far doesn't seem sufficient:

  • Permissive file in restrictive dir: Changing the umask to 0777 and the mode of a directory to 0770, one can grant read-write access within a group and lock out the rest of the world. The dir should also have to have the sgid bit set so its files get the correct group instead of the user's primary group. But an umask of 0777 has a risk of opening large holes in places not restricted in this fashion, and umask doesn't count for much if people start moving stuff around using e.g. mv.
  • ACL defaults: Using setfacl one can set defaults for newly created files in a given directory. This is better than the above, but it only works for newly created files. Agin this won't work if people start moving files around, and again it won't work for cases where the umask is too restrictive.
  • Why do you consider "this won't work if people start moving files around" a valid argument against ACLs but not against your "I can be sure that as long as a user drops his file inside a certain directory, it will be writable and deletable by a given group"? What you want can easily be done with FUSE (maybe already has). – Hauke Laging Jun 7 '13 at 16:13
  • @HaukeLaging: I want the file permissions to change when people move files around. That's a concept which I find easier to communicate than modes and ownership. FUSE would be one way to accomplish that, I guess. The list doesn't contain a likely candidate. A fuse mount exposing all files with the same permissions should be easy. A single mount with different permissions for different dirs would be harder, but neccessary to avoid copying if users start moving files around. I'm thinking large media files here. – MvG Jun 7 '13 at 16:30
  • 1
    Look at bindfs. – Stéphane Chazelas Jun 7 '13 at 17:09
  • @StephaneChazelas: OK, I overlooked that one. Looks like a solution if you don't require efficient move semantics within different permission domains. If you want to write an answer for this, I'll gladly upvote it. Otherwise I'd write a post myself if nothing better turns up. – MvG Jun 7 '13 at 17:40
  • @MvG I just posted a long post describing how Unix ACL's work and why. I suggest you read it. You can do a recursive setfacl or chmod to ease management but you actually don't want permissions on files to change (for a variety of reasons, not the least of which is that files are the actual repositories for information so the restrictions put on them should trump what directory they happen to be in. default ACL's only exist because the assumption is information in the same area of the filesystem will have similar security requirements.) – Bratchley Jun 7 '13 at 18:38
3

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.

  • I hadn't realized that ACL default mask isn't ANDed to umask but really takes precedence; that is a huge step forward. Regarding one example I disagree. If you had inherited settings, then you could explicitely set more narrow restrictions on deftManeuver, and stand a good chance they'd stick. As it is, chances are that some change in policy will result in a blanket setfacl -R accounting, since a non-recursive change won't be sufficient. Then we are in the scenario you described. – MvG Jun 7 '13 at 21:18
  • On your counterpoint: The group in question is new so there wouldn't be any lower level ACE to override it. Even if there were, you're basically doing what exists now: recursively setting permissions on the specific folder. The point I'm making by not having it inherit automatically is that forcing people to do it manually (even if recursively) is building in a step in where the administrator has to "tell" the system that's what they want to have happen rather than the system just assuming they're intimately aware of every part of the directory tree. – Bratchley Jun 7 '13 at 22:18
  • I also gave specific examples towards the end where the functionality has paid off in my own personal experience. – Bratchley Jun 7 '13 at 22:19
1

You might be able to achieve something similar by misusing AppArmor. The question however is whether it is a good idea - generally, permissions should be associated with data, not with a storage area, since otherwise users with access could elevate the permissions to anybody just by moving the files around.

While one can argue that the even just read access allows them to copy the data, your intended solution gives modification rights to somebody who should never have them (e.g. a secretary changing blueprints of the latest car engine).

  • I thought about using grsecurity in a similar approach, but preferrably I'd like users to be able to control access, just in an inheritable way. One cases I have in mind are groups working in a common writable dir, where one often can modify an accidentially write-protected file in any case by copying it then deleting the original. So the things users can do won't change that much, but the effort required to understand them would be massively reduced. – MvG Jun 7 '13 at 21:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.