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.
The installation of Apache may appears to be running as root but in actuality it's running as the user apache
. You can check this by looking in this file:
$ grep "^User" /etc/httpd/conf/httpd.conf
User apache
Your entire wordpress directory should likely be owned by this user if you're planning on managing the installation using wordpress through the web UI.
I usually create a separate directory for wordpress like this:
$ pwd
/var/www
$ ls -l | grep wordpress
drwxr-xr-x. 5 apache apache 4096 Apr 25 19:27 wordpress
Here's the contents of the wordpress directory just so you can see it:
-rw-r--r--. 1 apache apache 395 Jan 8 2012 index.php
-rw-r--r--. 1 apache apache 5009441 Jan 23 13:40 latest.tar.gz
-rw-r--r--. 1 apache apache 19929 May 6 2012 license.txt
-rw-r--r--. 1 apache apache 9177 Jan 25 11:25 readme.html
-rw-r--r--. 1 apache apache 4663 Nov 17 2012 wp-activate.php
drwxr-xr-x. 9 apache apache 4096 Dec 11 2012 wp-admin
-rw-r--r--. 1 apache apache 271 Jan 8 2012 wp-blog-header.php
-rw-r--r--. 1 apache apache 3522 Apr 10 2012 wp-comments-post.php
-rw-rw-rw-. 1 apache apache 3466 Jan 23 17:15 wp-config.php
-rw-r--r--. 1 apache apache 3177 Nov 1 2010 wp-config-sample.php
drwxr-xr-x. 7 apache apache 4096 Apr 24 20:15 wp-content
-rw-r--r--. 1 apache apache 2718 Sep 23 2012 wp-cron.php
drwxr-xr-x. 9 apache apache 4096 Dec 11 2012 wp-includes
-rw-r--r--. 1 apache apache 1997 Oct 23 2010 wp-links-opml.php
-rw-r--r--. 1 apache apache 2408 Oct 26 2012 wp-load.php
-rw-r--r--. 1 apache apache 29310 Nov 30 2012 wp-login.php
-rw-r--r--. 1 apache apache 7723 Sep 25 2012 wp-mail.php
-rw-r--r--. 1 apache apache 9899 Nov 22 2012 wp-settings.php
-rw-r--r--. 1 apache apache 18219 Sep 11 2012 wp-signup.php
-rw-r--r--. 1 apache apache 3700 Jan 8 2012 wp-trackback.php
-rw-r--r--. 1 apache apache 2719 Sep 11 2012 xmlrpc.php
I usually also manage any Apache configs related to wordpress in it's own wordpress.conf file under this directory,
/etc/httpd/conf.d/`.
# wordpress.conf
Alias / "/var/www/wordpress/"
<Directory "/var/www/wordpress/">
Order Deny,Allow
Deny from all
#Allow from 127.0.0.1 192.168.1
Allow from all
AllowOverride all
</Directory>
#RewriteLog "/var/www/wordpress/rewrite.log"
#RewriteLogLevel 3
Best Answer
setfacl
has a recursive option (-R
) just likechmod
:it also allows for the use of the capital-x
X
permission, which means:so doing the following should work:
(all quotes are from
man setfacl
for acl-2.2.52 as shipped with Debian)