Traditional Unix permission model

(feel free to skip this, if you already know about this)

Traditionally, the Unix permission model only specifies three scopes, the user, the group and the other scopes. If I run touch test creating an empty file with default permissions, the result looks like

$ ls -l
[...]
-rw-r--r-- 1 carsten     atlas   0 May 18 06:10 test
$ stat
[...]
Access: (0644/-rw-r--r--)  Uid: ( 5001/ carsten)   Gid: ( 5000/   atlas)

For each of the three mentioned scopes, one can flip the bits to enable or disable the read, write and execute permissions[1] for this file. Running chmod 0740 test[2] would change the permissions to

Access: (0740/-rwxr-----)  Uid: ( 5001/ carsten)   Gid: ( 5000/   atlas)

in other words, the user can read/write and execute the file (e.g. if it were a script), everyone from the same group could read it, but no one else can look at the file.

Directories are a bit different as read means, one can browse the filenames but nothing else(!) of a directory, write means one can add or delete files from a directory and execute means one enter and interact with a directory. For example, if a user had only the read permission for a directory the following may happen

ls ~user/read_only_dir
test
ls -l ~user/read_only_dir
ls: cannot access '/path/to/read_only_dir/test': Permission denied
total 0
?????????? ? ? ? ?            ? test

POSIX ACL

The downside of the traditional model is that it is not easily capable of mapping to smaller or dynamic groups. In theory, any combination of wanted users could be placed into a new group, but that usually strains the administration side of systems quite a bit as these need to be defined and rolled out to every machine.

POSIX ACLs try to solve this problem by adding a few new tools to extend this permission model, please check this linux.com article article for a more in-depth explanation.

In practice, you would use getfacl to get the information about the traditional and the extended permissions and setfacl to manipulate those.

For example, one wanted to share a directory with two collaborators within Atlas (userA and userB), they should have write capabilities there but no one else should be able to access the contents. Then, this should then work:

$ cd ~
$ mkdir collab_dir
$ chmod 0700 collab_dir
# at this point, only I should be able to access this directory
$ getfacl collab_dir
# file: collab_dir
# owner: carsten
# group: atlas
user::rwx
group::---
other::---
# add both users with full access rights
$ setfacl -m user:userA:rwx collab_dir
$ setfacl -m user:userB:rwx collab_dir
# let's check the current status
$ getfacl collab_dir
# file: collab_dir
# owner: carsten
# group: atlas
user::rwx
user:userA:rwx
user:userB:rwx
group::---
mask::rwx
other::---

At this point, the collaboration can start within this directory (hierarchy) without any changes to the operating system, i.e. defining/creating new groups there.

A potential trap exists here: If either userA or userB cannot access this directory - especially if it is located way down in the file system hierarchy - one needs to check every parent directory whether the users have the execute permission for every single one of them!

Finally, files or directories which have extra/extended ACLs defined can easily be spotted by the extra + when looking at the output of ls -l:

ls -l collab
-rw-rwxr--+ 1 carsten     atlas   0 May 18 07:47 test_file

Footnotes

[1] There are more than these three “bits” but these usually have very specific functions and should probably not affect daily user operation.

[2] The prefixed ‘0’ is just a convention as the number used here is “octal” based, one could also use chmod u=rwx,g=r,o= test for the same effect.