Granting Special Permissions

Overview

In some cases it may be desirable or necessary to selectively grant other users access to a particular directory or file. It is possible to do this on Matilda using "Access Control Lists" (acls). acls can be assigned to a file and/or directory on a user or group level, and can control all access bit permissions (read, write, execute). This document presents how to use acls, and where they can be employed.

Please note setting acls can be somewhat complex, and this document is intended only to provide users with some of the most commonly used commands for adding or removing acls from select files or folders. If you are concerned about data security and permissions, and are unsure of how to properly use acls, please email [email protected] for assistance.

What are acls?

acls are a part of the Linux operating system and provide fine-grained control over file and directory access to specific users or groups. A prerequisite for using acls, is that the root directory tree must have acls enabled as part of its mount. If a filesystem is mounted without acls enabled, you will not be able to use them on any directory or file that is part of that filesystem.

Where can I use acls?

On Matilda, acls can be used anywhere in the "scratch" spaces (e.g. /scratch/users, /scratch/projects). You can set acls if you are the owner of the directory or file.

Please note however, both the /home and /projects directory mounts do NOT have acls enabled, and as such they cannot be used in these filesystem directory trees.

Using acls: Examples

User Level

Suppose we have a file "mydata.dat" in the "/scratch/projects/myproj" directory. You are the owner (user piuser) and the permissions are currently set as follows:

[[email protected] myproj]$ ls -l mydata.dat
rw-r----- 1 piuser myproj   27 Oct 27 11:29  mydata.dat

[[email protected] myproj]$

If we want to grant permission to the user "mary2022" (who is a member of our project group "myproj") to write to the file, we can modify the acls using the following:

[[email protected] myproj]$ setfacl -m user:mary2022:rw- mydata.dat
[[email protected] myproj]$

Now we can verify the acls on that file using:

[[email protected] myproj]$ getfacl mydata.dat
# file: mydata.dat
# owner: piuser
# group: myproj
user::r--
user:mary2022:rwx
group::---
mask::rwx
other::---

[[email protected] myproj]$

Let's dissect the command "setfacl -m user:mary2022:rw- mydata.dat"

  • -m -- indicates we are "modifying the acls"
  • user:mary2022:rw- -- we are assigning read and write (no execute, note the "-") permissions to the user "mary2022" for mydata.dat

A similar process can be used for a directory. Suppose we want to allow "mary2022" to write to a subdirectory "/scratch/projects/myproj/simulationResults" and to read any of the files in that subdirectory, but not to write to any of the existing files. Currently, the read and write permissions are set to owner only (piuser). First we need to set the read, write, and execution permissions on the folder to permit "mary2022" to write new files, read existing files, and to navigate the folder (the execution permissions):

[[email protected] myproj]$ ls -l
drwx--S---  2 piuser myproj 4096 Nov 16 09:39 simulationResults

[[email protected] myproj]$ getfacl simulationResults
# file: simulationResults
# owner: piuser
# group: myproj
# flags: -s-
user::rwx
group::---
other::---

[[email protected] myproj]$ setfacl -m user:mary2022:rwx simulationResults
[[email protected] myproj]$ getfacl simulationResults
# file: simulationResults
# owner: piuser
# group: myproj
# flags: -s-
user::rwx
user:mary2022:rwx
group::---
mask::rwx
other::---

[[email protected] myproj]$

Now we need to set the read permissions for the existing files:

[[email protected] myproj]$ cd simulationResults
[[email protected] myproj]$ ls -l
total 8
-rw------- 1 piuser myproj 9 Nov 16 09:44 myresults1.dat
-rw------- 1 piuser myproj 9 Nov 16 09:44 myresults2.dat

[[email protected] myproj]$ setfacl -m user:mary2022:r-- *
[[email protected] myproj]$ getfacl myresults1.dat
# file: myresults1.dat
# owner: piuser
# group: myproj
user::rw-
user:mary2022:r--
group::---
mask::r--
other::---
[[email protected] myproj]$

Group Level

A similar process can be used for groups as shown above for users. We would simply replace the "user" portion of the commands with "group". Note also, a shorthand version of "user" (u) and "group" (g) can be used. For example:

[[email protected] myproj]$ setfacl -m group:smith-lab:r-- somefile.dat

It is unlikely that most Matilda users would need to alter group permissions, since most project groups are self-contained and restricted only to members of that project group. But there could be scenarios where limited read access might be needed between collaborating Matilda users. At a minimum, you would need to alter the acls at the root project directory level (e.g. /scratch/projects, setfacl -m g:somegroup:r-x myproj), and then set the permissions as-needed in the project directory tree to reach the desired file or folder. Remember, the executable bit ('x') must be set at each directory or subdirectory where navigation access is needed. If in doubt on how to do this safely, please send an email to [email protected] .

Removing acls

Removing User or Group acls

To modify an existing acl (e.g., you've granted read and write permissions to a user or group and want to change it to read-only):

[[email protected] myproj]$ setfacl -m user:mary2022:r-- myresults.dat

To totally remove a user or group acl from a file or folder:

[[email protected] myproj]$ setfacl -x user:mary2022 myresults.dat
OR
[[email protected] myproj]$ setfacl -x user:mary2022 myfolder

Remove all acls

To remove all acls from a file or folder:

[[email protected] myproj]$ setfacl -b myresults.dat
OR
[[email protected] myproj]$ setfacl -b myfolder

Remember to double check the folder of file to ensure that the desired default permissions are restored as-needed.

More Information


HPC