Increase security of your web server
I struggled understanding the last revision of this section. I tried to reproduce it in a more clear way, but I'm not sure I achieved what the original author was trying to do.
I still think that the example lacks necessary real world applicability. If at all, the web server should only have access to a specific folder within the user's home directory.
Any more suggestions?
You can now add permissions to our home directory and/or site directory only to nobody user any anyone else - without "whole world" to increase your security.
Add permissions +x for nobody user on your home directory via ACL:
# setfacl -m "u:nobody:--x" /home/homeusername/
Now you can remove whole world rx permissions:
# chmod o-rx /home/homeusername/
Check our changes:
# file: username/ # owner: username # group: users user::rwx user:nobody:--x group::r-x mask::r-x other::---
As we can see others do not have any permissions but user nobody have "x" permission so they can "look" into users directory and give access to users pages from their home directories to www server. Of course if www server work as nobody user. But - whole world except nobody - do not have any permissions.
- Is the section relevant only for Apache or also other web servers? -- Lahwaacz (talk) 10:16, 17 April 2015 (UTC)
- I think Foggs didn't understand that in order to access a specific directory at a user's home directory, the web server must have permissions to access that home directory first. The web server can not skip the home directory when it traverse the path to a directory under the home directory. It can be regarded unfortunate that access permissions can not be granted just to the exact directory the web server should look into. But that is how traversing the file system works. Which is why it was, and still is, a real world example. And that is also the reason the section is relevant for any web server that traverses the file system. Not just to the Apache web server.
- As an aside, other mechanisms might be better alternatives. I am aware of bind mounts.
- Regid (talk) 03:29, 17 December 2020 (UTC)
ACL mask entry
The original note about the
--mask option (which was taken from ) was determined as inaccurate, but the new note does not seem correct either.
Let's do a quick test:
$ touch test $ chmod 755 test $ getfacl test
# file: test # owner: lahwaacz # group: lahwaacz user::rwx group::r-x other::r-x
So the group has r-x permissions, which is what the note talks about. Let's add an ACL for user root with rwx permissions:
$ setfacl -m u:root:rwx test $ getfacl test
# file: test # owner: lahwaacz # group: lahwaacz user::rwx user:root:rwx group::r-x mask::rwx other::r-x
The result is not what the note says: root has full rwx access to the file, there is no "effective" r-x permission. Especially, getfacl says the mask is rwx, not r-x.
Interestingly, note that the (effective?) group permissions changed:
$ ls -lah test
-rwxrwxr-x+ 1 lahwaacz lahwaacz 0 Sep 2 10:12 test
When you run
setfacl -b test, it will be the original 755 again. Or when you
chmod 755 test, the mask entry will change and result in effective r-x permission for user root:
$ chmod 755 test $ getfacl test
# file: test # owner: lahwaacz # group: lahwaacz user::rwx user:root:rwx #effective:r-x group::r-x mask::r-x other::r-x
This is completely different behaviour than what the note currently says.
Just as an aside, using root in an authorization example is maybe not the best way to test. For example, I recently got burned by the fact that sometimes the system treats a user's matching group the same as the user; e.g. if you restrict the access of user foo in /etc/security/access.conf, it will apply the same restrictions to the group foo.
Here is my real world example:
root@kraken:/EM# ls -ld acltest drwxr-s---+ 2 mclellanimages mclellanlab 10 Sep 6 09:51 acltest root@kraken:/EM# getfacl acltest # file: acltest # owner: mclellanimages # group: mclellanlab # flags: -s- user::rwx group::r-x other::--- default:user::rwx default:user:jmclellan:rwx default:group::r-x default:mask::rwx default:other::---
I created a default ACL for this folder using
# setfacl -d -m u:jmclellan:rwX acltest
root@kraken:/EM# cd acltest root@kraken:/EM/acltest# touch a root@kraken:/EM/acltest# ls -l total 0 -rw-rw----+ 1 root mclellanlab 0 Sep 6 09:54 a root@kraken:/EM/acltest# getfacl a # file: a # owner: root # group: mclellanlab user::rw- user:jmclellan:rwx #effective:rw- group::r-x #effective:r-- mask::rw- other::---
Notice that it gave the group write permissions even though the umask for root is 755. The files in the actual data folder are placed there by a script, and the group should only have read permissions. The mclellanimages user is programmatic; the actual human who should be able to edit the files is jmclellan, and so far that permission is intact. But watch what happens if write permission is removed from the group:
root@kraken:/EM/acltest# chmod g-w a root@kraken:/EM/acltest# ls -l total 0 -rw-r-----+ 1 root mclellanlab 0 Sep 6 09:54 a root@kraken:/EM/acltest# getfacl a # file: a # owner: root # group: mclellanlab user::rw- user:jmclellan:rwx #effective:r-- group::r-x #effective:r-- mask::r-- other::---
Notice that jmclellan's effective permissions on this file are now r--, and he can no longer edit the file. This is what my editing of the note on the Wiki page was intended to illustrate. This surely is one of the most common use cases for extended POSIX ACLs. N people have full privileges (in this case, 2), but read access is afforded to a much larger group. I found the way this works endlessly confusing until I figured out what was going on, which is why I was trying save the next POSIX ACL user the same frustration by updating this note.
(In the example above I did not reset the ownership of the file to mclellanimages, but the behavior is exactly the same when I do.)
This is what the setfacl man page says:
The default behavior of setfacl is to recalculate the ACL mask entry, unless a mask entry was explicitly given. The mask entry is set to the union of all permissions of the owning group, and all named user and group entries.
As you can see from my example, that is absolutely not correct: the mask entry is set to the intersection of all permissions.
Note further that the --no-mask flag doesn't seem to work, either:
root@kraken:/EM/acltest# setfacl --no-mask -m u:pgoetz:rw- a root@kraken:/EM/acltest# getfacl a # file: a # owner: root # group: mclellanlab user::rw- user:jmclellan:rw- #effective:r-- user:pgoetz:rw- #effective:r-- group::r-x #effective:r-- mask::r-- other::---
So, what's not documented anywhere is the way to get around this. What you do is set very permissive minimal POSIX permissions for a group which consists of just the user, and then use POSIX extended ACLs for all actual permissions:
root@kraken:/EM# ls -ld acltest drwxrws--- 2 mclellanimages mclellanimages 10 Sep 6 10:33 acltest root@kraken:/EM# setfacl -d -m u:jmclellan:rwX acltest root@kraken:/EM# setfacl -d -m g:mclellanlab:rX acltest root@kraken:/EM# cd acltest root@kraken:/EM/acltest# touch a root@kraken:/EM/acltest# ls -l total 0 -rw-rw----+ 1 root mclellanimages 0 Sep 6 10:33 a root@kraken:/EM/acltest# chown mclellanimages a root@kraken:/EM/acltest# ls -l total 0 -rw-rw----+ 1 mclellanimages mclellanimages 0 Sep 6 10:33 a root@kraken:/EM/acltest# getfacl a # file: a # owner: mclellanimages # group: mclellanimages user::rw- user:jmclellan:rwx #effective:rw- group::rwx #effective:rw- group:mclellanlab:r-x #effective:r-- mask::rw- other::---
- I am confused by the discussion so far. Still, I think is quite short, and quite clear. Though I haven't tested to see if the actual behavior corresponds to the way I understand that section.
- As an aside, do Pgoetz, or the wiki editors, allow me to indent Pgoetz reply from above in a way that is more common for threaded discussions?
- Regid (talk) 01:51, 17 December 2020 (UTC)