Understanding file and group permissions

This doc is intended to help you understand POSIX-style file ownership and group permissions on Unix-like systems such as Linux. As the FASRC cluster is built upon Linux and various storage technologies that follow or mimic the POSIX standards, this applies to almost all files and directories on FASRC storage.

Ownership and Access Groups

Owner Group Other

These are the three permission sets applied to files and directories.

Owner is a single user. The account/user who is the owner of the file. Regardless of Group or World access, the owner has access to modify or remove the file.
Group is a collection of users (such as your lab group). The owner of a file or directory may extend and control access permissions (read, write, execute) for a single group.
Other (aka Everyone or World) indicates all other valid users on the system. This can be used to grant or deny access to all valid users in the system.

If you have used the ls -l command in a terminal, you have seen this signified like so:

drwxr-x--- jharvard jharvard_lab 4096 Dec 10 2021 MyData -rwxrwxr-x jharvard jharvard_lab 3257 Feb 23 17:21 myscript.sh

The d in the first line indicates that this object is a directory. It has read, write (aka modify), and execute (rwx) permissions for the Owner, read and execute permissions for the Group, and no permissions for Other. This means: Owner jharvard has full access to this directory (and can change permission at will via the chmod command). Group jharvard_lab can read and execute files in this directory, but cannot modify it. All other users who might have access to this share have no access to this directory.

The second object is a file (hence the -, signifying ‘not’ or ’empty’ value, in place of d). It has read, write, and execute permissions for the Owner, read, write, and execute permissions for the Group, plus read and execute permissions for Other. This means jharvard has full access to the file (and can change permission at will via the chmod command). Group jharvard_lab can read, write/modify, and execute this script. Other, assuming they have access to this share, can read and execute this script.

Note that for Other to actually have access, they would need also to be able to access the top-level share itself. We’ll go over this a litttle further down.

Permissions in Practice – A Quick Metaphor

Let’s look at your lab directory or tiered storage share as an example, but using a metaphor. In most cases, these directories/shares havc a top-level permission like

drwxr-xr-x – Meaning the Owner (probably your PI) has rwx access to the share, the Group has r-x access to the top-level but generally have write access to sub-directories within (see One,Many, All below), and all other users not in the group have potential read and execute access on any file or directory inside the share that explicitly allows access to Other (like myscript.sh in the earlier example), but otherwise no access.

If the top-level of the lab directory or share is set drwxr-x--- or drwxrwx— or drwxr-s---, then Other has no access to the directory/share, even if a file inside is set -rwxrwxrwx. Other must first be able to ‘see’ into the directory/share. Otherwise, it has no access at all. Please note that FASSE/L3 shares should never allow Other access.

To our metaphor:

Say you have a keycard to let you into your group’s office building and its common areas. That keycard also let’s you open your private office door, your keycard is required again to open the door to exit to the common area. Your office also has a large window to the outside that you can open and close with your keycard.

You and all your co-workers can access the building and common areas using your individual keycards.

Each person can open their own office door with their personal keycard. You can, if you wish, also set your office door to allow other members of your group to open it with their keycards. You can revoke this permission at any time.

Now let’s imagine your building is inside a secure compound, and not accessible to the public (like the FASRC cluster). And you want to allow other people in the compound to come into your office any time they wish, but not have access to your group’s common areas. You can do so by opening the window to the outside world. They can enter your office, but they cannot open the office door to the rest of the building as they are not you (Owner) or part of the group (Group). But you cannot control who comes in, it could be anyone inside the compound.

If you need to allow a single person from outside, you could ask your boss to make them a member of your Group, which would then give them keycard access to the building and common areas. If you have set your door to allow members of your group to open it, then this person would now also have access to your (and potentially other group members’) office door.

This is analogous to the POSIX permissions scheme works: Owner is a single user, Group is a curated (by your PI) collection of users, and Other is everyone else on the cluster.

One, Many, All

As you can see, this doesn’t allow for ‘I want this person and this person’ to have access, but not this person’. POSIX permissions require conforming to the idea of one, many, and all. One being the Owner, many being the Group, and All being Other, which is everyone else on the cluster, in this case.

To facilitate this idea, lab directories and tiered shares (except FASSE/L3 shares) by default contain some special directories to help ease the issues of sharing within a POSIX-like environment:

Lab – This directory is set drwxrws– so that every member of the lab group has read/write/execute (the s here being the setuid bit, for this discussion just think of it as is equivalent to x ) access to share data amongst the group. This directory is also visible to lab group members when accessing the share via Globus (if applicable).

Users – The sub-directories in this directory are owned by individuals and by default only allow execute (using the setuid bit as above) access to the group. You may, if you wish, make your Users directory open to others in the group using the chmod command. But using the Lab directory instead is the preferred method to share data with your lab group. This directory is also visible to the owner (and only the owner) when accessing the share via Globus (if applicable).

Everyone – This directory is set drwxrwsr-x and is useful for sharing data with Other (all other cluster users). This directory is not available from Globus.

Search Docs by Keyword

Understanding file and group permissions

Ownership and Access Groups

Permissions in Practice – A Quick Metaphor

One, Many, All

Related Links