Restrict student account permissions, give faculty access

ACLs are the answer. The students don't need any special permission to run setfacl, a user can set the ACL of any file that he owns.

If you need to set up your system for ACLs, see Make all new files in a directory accessible to a group

Tell students that if they need a file to be accessible to Apache, then they must run

setfacl -m group:daemon:r ~/path/to/password.file
setfacl -m group:daemon:x ~ ~/path ~/path/to

The x permission on the directories is necessary to access files (including subdirectories) in these directories.

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.