Talk:Access Control Lists

From ArchWiki
Jump to navigation Jump to search

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?

Original section

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.

—This unsigned comment is by Foggs (talk) 13 April 2015 20:46. Please sign your posts with ~~~~!

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 setfacl(1)) 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.

Lahwaacz (talk) 09:21, 2 September 2020 (UTC)

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

Now:

   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::---

Pgoetz (talk) 15:52, 6 September 2020 (UTC)

I am confused by the discussion so far. Still, I think acl(5) § CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS 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)