Sharing data with other cluster users
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.