This page explains how you can share data with others, and in general, how you can manage access to your stuff.

This mainly applies to things in your /labs and /projects space, as well as other paths on /oak. Files in your home directory are private by default. Files in scratch & temporary space are also private by default.

This section starts with a description of how permissions work, and how you can find out what they are. After that, there is a section explaining how things can be changed.

About Permissions¶

Every file and directory has a set of permissions. On the command line, you can see them when you do a “long listing” with the ls -l command.

Here is the output of a long listing, with a short explanation for each column:

[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ ls -l /labs/ruthm/akkornel
total 12717836
-rw-r-----+ 1 akkornel scg_lab_ruthm   747025940 Oct 18 20:17 Building Debian
Packages.mp4
-rw-r-----+ 1 akkornel scg_lab_ruthm 12276008960 Feb 17  2022 homes.tar.gz
drwxrws---+ 7 akkornel scg_lab_ruthm        4096 Oct 13 11:29 HuBMAP_inbound
drwxrws---+ 8 akkornel scg_lab_ruthm        4096 Sep 13  2020 jupyter
drwx--S---+ 2 akkornel scg_lab_ruthm        4096 Jul 24 16:20 secret
─────┬───── ┬ ─────┬── ──────┬────── ─────┬───── ─────┬────── ───────┬───────
     ▼      │      ▼         │            │           │              ▼
Permissions │ Owning user    │            │           │            Name
            │                ▼            │           │
            │          Owning group       │           ▼
            │                             │      For files: The last-modified date.
            ▼                             │      For directories: The last time the
For files: The number of "hard links" to a│      directory's listing was modified.
file.  Often this is 1.                   │
For directories: The number of things     │
pointing to this directory.               │
                                          ▼
                                     For files: The file size (in bytes)
                                     For directories: The size of the listing.

In this guide, we only care about the columns related to permissions. When it comes to managing permissions, we are about three columns: The Permissions column, the Owning User, and the Owning Group.

Owning Users & Groups¶

The Owning User is the simplest field: The Owning User is the person who created the file, or who created the directory.

The owning group is slightly more complicated: Every user has a “primary group”. When you run the id command, your primary group is the first group listed:

[akkornel@smsh11dsu-srcf-d15-38 akkornel]$ id
uid=271766(akkornel) gid=4327(upg_akkornel) groups=4327(upg_akkornel),1618(scg-admin),1619(scg-users),…

In the above example, akkornel‘s primary group is upg_akkornel. You also see this when you run scgwhoami:

[akkornel@smsh11dsu-srcf-d15-38 akkornel]$ scgwhoami
SCG Account Information
       Real Name: Karl Kornel
        username: akkornel
       uidNumber: 271766
           $HOME: /home/akkornel
   primary group: upg_akkornel
       gidNumber: 4327

……… remaining output cut for brevity ………

By default, the Owning Group is the Owning User’s primary group. But this behavior can be modified: If the parent directory has a special flag set (known as the “setgid” or “set group ID” flag), then instead of using the Owning User’s primary group, new files and directories will inherit the group of its parent.

The “setgid” flag is set on by default throughout Lab and Project storage: We want all files within a lab’s space to have the lab’s group be the Owning Group.

Common Groups on SCG¶

As you use SCG, you will come across a number of common groups that act as Owning Groups for files & directories. Here is what they are:

• Your private group (UPG, or “User Private Group”): Every SCG user has their own private group. If your SUNetID is abc, your private group will be upg_abc. The private group is used as the Owning Group for the files in your home directory.

• Lab groups: Every lab has a group, named after the PI’s SUNetID: If the PI’s SUNetID is abc, the lab’s group will bescg_lab_abc. Lab groups are only used in /labs space, and in /oak.

• Project groups: Stand-alone projects have their own group, named after some identifier associated with the group. For example, the (fictional) Asystolic Bypass Control project might have the group scg_prj_abc. Project groups are only used in /projects space, and in /oak.

• Oak groups: The Oak Storage Service is accessible through SCG, at path /oak. Groups associated with this service have names starting with oak_.

• Nobody: The special group nobody appears on SCG at a number of locations. When you see it in /labs, /projects, and /oak space, that is a sign of files & directories that have lost their group association when being moved: Oak does not recognize all of SCG’s groups, and replaces unrecognized groups with nobody. When you find items inside /labs and /projects space with an Owning Group of nobody, you should change the group to something appropriate.

• Numeric groups: Internally, SCG stores groups as numbers instead of names. If you see a group listed as a number, that group no longer has an entry in the list of groups. You will see this most often inside containers.

Basic Permissions¶

The first column of the ls -l listing shows the permissions for an item.

The first column has eleven fields: One character identifies the type of an item, three groups of three characters specify basic permissions, and the last character tells us if the item has more-detailed permissions (a full “Access Control List”, or “ACL”) that cannot be fully-displayed in just eleven characters.

Here is a breakdown of what the different fields mean:

drwxrwxrwx+
│   ─┬─   │
│─┬─ │ ─┬─└─▶If +, this entry has a full ACL.
│ │  │  │
│ └──┼──┼───▶Permissions for the item's owner
│    │  │
│    └──┼───▶Permissions for the item's group
│       │
│       └───▶Permissions for everyone else
│
│   - means "This is a file"
└──▶d means "This is a directory"
    l means "This is a symlink to something else"

Each type of permissions (owner, group, and ‘other’) has three characters. If a target (owner, group, or ‘other’) has a given permission, the appropriate letter (r, w, x, etc.) will be displayed; if a target does not have a given permission, a - character will be displayed.

Here is what the different permissions letters mean:

• r: For files, the target is able to read the contents of the file. For directories, the target is able to see a directory listing.

• w: For files, the target is able to change the contents of the file. For directories, the target is able to create new files, move items in, rename things, delete things, etc..

• x: For files, the target is able to execute the file as a program or a script. For directories, the target is able to cd into the directory.

Here are some examples of permissions that you will see:

• -rwxr-xr-x: This file (a program or script) has read+write+execute permissions (full permissions) for the Owning User, and everyone else just has read+execute permissions.

• -rw-r-----: This file has read+write permissions for the Owning User, read-only for the Owning Group, and others do not have access.

• -rw-r--r--+: This file has read+write permissions for the Owning User, and read-only for everyone else. But the + flag means there is a full ACL in place, so we would need to read the full ACL to understand the permissions. ACLs will be covered in the next section.

The above permission flags can be combined in interesting ways. Here are some examples:

• It is possible to give --x (execute but not read) on a file, which should allow a user to execute a program without being able to read its contents. But this does not work for scripts: The interpreter (Bash, Python, R, etc.) needs to be able to read the file, so if you want someone to run your program, they need r-x (read+execute) permissions.

• Say you have a parent directory, and that parent directory contains a sub-directory. You want to give a user permission to read the sub-directory, but not the parent. To do that, you give --x (execute only) permissions on the parent directory, and r-x (read + execute) on the sub-directory. By giving --x on the parent directory, the user can use the cd command to travel through the parent directory, but an ls inside the parent will fail.

There are two other permission letters that you commonly see, and should be aware of:

• s: For directories, an s in the Group permission means the x (execute) flag is set and “setgid” flag is turned on: Things created inside this directory will inherit the directory’s Owning Group.

• S: For directories, an S in the Group permission means the “setgid” flag is turned on, but the x (execute) flag is not.

There are other permission letters that can appear in listings (like t, or s on files), but those are more-complex permissions, and are fairly rare.

Basic Permissions as Numbers¶

In some environments, basic permissions will be represented as numbers. Basic permissions can be represented in binary, or in octal (base-8) numbers. One octal digit takes three bits, so in numeric form, permissions are represented as three or four octal digits, with a leading zero. This diagram shows how human-readable basic permissions map to their binary and octal form:

┍7┑ ┍7┑┍7┑┍7┑  Octal sum
4┊┊ 4┊┊4┊┊4┊┊  ┐ Equivalent
 2┊  2┊ 2┊ 2┊  ┝ Decimal
  1   1  1  1  ┘ Values
111 111111111  Binary
│││drwxrwxrwx+ Human-Readable
│││    ─┬─
│││ ─┬─ │ ─┬─
│││  │  │  │
│││  └──┼──┼───▶Permissions for the item's owner
│││     │  │
│││     └──┼───▶Permissions for the item's group
│││        │
│││        └───▶Permissions for everyone else
│││
└┼┼──▶"setuid" flag (aka "setuid bit")
 ││
 └┼──▶"setgid" flag (aka "setgid bit")
  │
  └──▶"sticky bit"

When repsenting permissions in octal form, permissions always start with a leading 0. In binary form, they start with a leading 0b.

Here are some examples of common permissions used on SCG, and their octal forms:

• -rwxr-xr-x == 0b000 111 101 101 == 0755 Owner has read+write+execute permissions; everyone else has read+execute permissions.

• -rwxrwxr-x == 0b000 111 111 101 == 0775 Owner and group have read+write+execute permissions; everyone has read+execute permissions.

• -rw-rw-rw- == 0b000 110 110 110 == 0666 Everyone has read+write permissions.

• -rw-rw-r-- == 0b000 110 110 100 == 0664 Owner and group have read+write permissions; others have read permissions.

• -rw-r--r-- == 0b000 110 100 100 == 0644 Owner has read+write permissions, others have read.

• -rw-r----- == 0b000 110 100 000 == 0640 Owner has read+write permissions, group has read, everyone else has no access.

• drwxr-sr-x == 0b010 111 101 101 == 02755 This is a directory. The setgid flag is on. Owner has read+write+execute permissions; everyone else has read+execute permissions. Remember, octal permissions always start with a 0, so the octal form is now four digits long.

• drwxr-s--- == 0b010 111 101 000 == 02750 This is a directory. The setgid flag is on. Owner has read+write+execute permissions, group has read+execute permissions, others have no access.

• drwx--S--- == 0b010 111 100 000 == 02700 This is a directory. The setgid flag is on. Owner has read+write+execute permissions. Group has no permissions, but since the setgid flag is on, there is an S in the group-execute slot. Others have no access.

umask and New Files¶

When a new item is created, the program creating the item must decide what its permissions should be. Although Basic Permissions do say what the permissions are for existing items, it does not have a way to specify what the permissions should be for new items. To configure that, the system consults the “umask” (User Mask).

The umask is a three-digit octal number (since it must be an octal number, a leading zero is not needed). But instead of specifying what the default permissions should be, the umask specifies what permissions should be withheld. For example, permissions of 0022 translates to “write permission for the Owning Group and others”; when 022 is used as a umask, it means “disable write permission for the Owning Group and others”.

To apply the umask to new items, the system looks to see if you (or a program you are running) wants to create a new file or a new directory. New files start out with permissions of rw-rw-rw- (octal 0666, read+write for all); new directories start out with permissions of rwxrwxrwx (octal 0777, read+write+execute for all). Starting with the default, the umask is applied, and the result is the permissions for the new item.

Using the starting permissions above, if the umask is 002, the default new-file permissions of 0666 become 0664 (rw-rw-r--, read+write for Owning User and Owning Group, read-only for others), and the default new-directory permissions of 0777 become 0775 (rwxrwxr-x, full access for Owning User and Owning Group, read+execute for others).

The default umask on SCG is 002, disabling write permission for others. To change the umask for a single session, run the command umask NEW_UMASK. For example, after running the command umask 007, others will not get access to newly-created items within that session. When you run the umask command in your current shell, it takes effect for that shell—and all programs run in that shell—until that session ends.

If you want to change your umask for all future sessions, you will have to modify the file named “.bashrc” in your home directory. Simply add a line like umask 007—or something similar—at the end of the file. The change will take effect in new sessions.

ACLs¶

Basic permissions and the umask work fine for many situations, but they do not work when you want to implement complex permissions. For example, you might want to give write access to another user in your lab, while keeping read access for everyone else in the lab. ACLs allow you to do that.

To get the ACL for an item, use the command getfacl ITEM. Here is a breakdown of an example ACL for the file a in directory d:

[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ getfacl d/a
# file: d/a              ┌─────▶Owning User
# owner: akkornel  ──────┘ ┌───▶Owning Group
# group: scg_lab_ruthm  ───┘
user::rw-  ─────────────────────▶Owning User permissions────┬─▶User permissions
user:melchua:rw-  ──────────────▶Access for a specific user─┘
group::rw-  ───────────────────┐
group:scg_lab_mpsnyder:r--  ──┐└▶Owning Group permissions────┬▶Group permissions
mask::rw-  ─────────────────┐ └─▶Access for a specific group─┘
other::---  ────────────────┼┐
                            │└──▶Permissions for everyone else
                            │
                            └▶Maximum permissions applicable to this item,
                              for people other than the Owning User.

In the output above, starting at the top, the Owning User and Owning Group are shown just like in the ls -l output. After that, each permission has its own line. There are lines for user permissions (starting with user:), group permissions (starting with group:), and others (other::).

At the end of each line, the same letters as Basic Permissions are used: r for read, w for write, and x for execute. Just like with Basic Permissions, the - is used to represent a permission that is not present. In the example above, the line group::rw- means that the Owning Group has read+write (not execute) permissions, and other::--- means that other users have no access.

The space in the middle of the entry is used to limit the permission to a specific user or group. For example, user:melchua:rw- gives read+write permissions to only user melchua, and group:scg_lab_mpsnyder:r-- gives read permissions to everyone in the group scg_lab_mpsnyder.

Even though the line for other users (other::---) has a space in the middle, that space is always kept blank.

Finally, the mask:: line is used to provide a hard limit on the pemissions that apply to everyone other than the Owning User. If something is more-permissive than the mask permissions, the mask permissions will be the effective permissions. Here is an example:

[akkornel@smsh11dsu-srcf-d15-37 d]$ getfacl b
# file: b
# owner: akkornel
# group: scg_lab_ruthm
user::rw-
user:melchua:rw-        #effective:r--  ────┬▶Effective permissions, after
group::rw-          #effective:r--  ────────┘ taking the mask into account.
mask::r--
other::---

In this example, user melchua and the Owning Group both should have read+write access. However, the mask is set to read-only. Since read-only is more restrictive than read-write, both user melchua and the Owning Group will be limited to read-only access. Other users do not have access at all, so their access is not affected by the mask. The mask never affects the Owning User, so they continue to have read+write access.

ACLs & Directories¶

ACLs for directories look similar to ACLs for files. Here is a breakdown of an example ACL for the directory d:

[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ getfacl d
# file: d
# owner: akkornel
# group: scg_lab_ruthm
# flags: -s-  ────────────────▶From left to right:
user::rwx                      setuid, setgid, and sticky flags
group::r-x
group:scg_lab_mpsnyder:r-x
mask::r-x
other::---
default:user::rwx                   ──┐
default:group::r-x                    │
default:group:scg_lab_mpsnyder:r-x    ├──▶Default permissions
default:mask::r-x                     │   to apply to new items
default:other::---                  ──┘

Just like for files, directory ACLs have an Owning User, Owning Group, and permissions. Those work the same as Basic Permissions: The read (r) permission gives access to list a directory’s contents (with ls); write (w) gives permission to modify the directory’s contents (moving files in, creating files, deleting files, etc.); execute (x) gives permission to traverse the directory (with cd).

Since directories often have the setgid flag set, this is shown in the # flags: line at the top of the output. From left to right; an s is used to show if the setuid, setgid, or sticky flag is set.

Finally, directories have a second set of permissions, all starting with default:. These “default permissions” are used to control what the permissions will be for things that are created inside the directory.

To understand how the system uses the default ACL for new files and directories, here is a breakdown of an example directory’s ACL, and how it is applied to a new file, plus a new sub-directory.

[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ getfacl d
# file: d
# owner: akkornel
# group: scg_lab_ruthm       Owning User has full access
# flags: -s-        ┌───────▶Owning Group has read+execute
user::rwx   ────────┤        Others have no access
group::r-x          │
mask::rwx           │      ┌▶Default permissions give write
other::---  ────────┘      │ access to Named User melchua
default:user::rwx          │
default:user:melchua:rw-  ─┘
default:group::r-x          umask blocks write access for others
default:mask::rwx                             ▲
default:other::---                            └─────┐
[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ umask    │
0002  ──────────────────────────────────────────────┘
[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ touch d/file
[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ mkdir d/dir
[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ getfacl d/file
# file: d/file
# owner: akkornel                             Named User melchua has
# group: scg_lab_ruthm         ┌─────────────▶write access to the
user::rw-                      │              newly-created file
user:melchua:rw-  ─────────────┘
group::r-x          #effective:r--             The execute bit defaults
mask::rw-         ────────────────────────────▶to off for all new files.
other::---
[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ getfacl d/dir
# file: d/dir
# owner: akkornel
# group: scg_lab_ruthm
# flags: -s-
user::rwx
user:melchua:rw-
group::r-x
mask::rwx
other::---
default:user::rwx        ───────┐
default:user:melchua:rw-        │
default:group::r-x              ├───────▶New directory's default ACL copies
default:mask::rwx               │        the default ACL of its parent.
default:other::---       ───────┘

In the example above, directory d allows full access for the Owning User, read+write access for the Owning Group, and no access allowed for others. The default ACLs are similar, except there is a default ACL for user melchua, giving read+write access. In this case, the ACL for user melchua is only a default ACL, which means this user does not have the ability to modify the directory themselves. For example, they cannot copy a file into the directory.

The umask (0002) is also shown. In this case, the umask blocks read access for others. The example then creates new file file and new directory dir.

For Basic Permissions—when ACLs are not used—the permissions for a new item are computed using hard-coded starting permissions and the umask. For ACLs, the permissions for a new item are computed using the default ACLs of the parent directory, the item type, and the umask.

For the new file, after copying the parent directory’s default ACL, all execute permissions are removed: Files default to read+write, not read+write+execute. This is implemented by modifying the Owning User ACL (user::), the others ACL (other::), and the mask (mask::). To learn why the change is implemented in this way, read the section at the end of this page, Using chmod on items with ACLs.

After execute permissions are removed, the umask is applied, removing whatever permissions were specified there. A umask of 002 means “Remove write permission for others”. Since the existing ACL is already other::---, other users have no access, and the umask has no effect. That results in the final ACL shown above.

As for the new directory, the same process is applied. The new directory’s ACL is copied from the default ACL of the parent directory. Since this is a directory, all execute permissions are not removed. The umask is applied (again, no effect in this example). Finally, the default ACL of the parent directory becomes the default ACL of the new directory.

Changing Ownership¶

Changing ownership of a file or directory needs to be done by a system administrator.

If you would like ownership on something changed, email scg-action. In your request, include the following:

• The exact path to the file or directory that needs an ownership change.

• If a directory, be clear in saying that you want to change ownership for the directory and all its contents.

• Provide the old and new owner SUNetIDs.

• CC either the old owner or the PI, and explicitly ask for their approval. Ask them to approve via a reply-all to your original email.

Once approval is received, we will process the ownership change.

If items have an ACL, this only changes the Owning User in the ACLs.

Changing Group¶

If you are the owner of a file or directory, and you are a member of the new group, you can change the Owning Group yourself.

To change the group of an item, run chgrp NEW_GROUP_NAME ITEM. For example, to change the group of file “abc” to group scg_lab_ruthm, run this command:

chgrp scg_lab_ruthm abc

If you want to change a directory and all its contents, use the -R flag, like this:

chgrp -R scg_lab_ruthm some_directory

If items have an ACL, this only changes the Owning Group in the ACLs.

Changing Permissions¶

You can change permissions on anything that you own. If you own a directory, you can change permissions on a directory, but you might not be able to change permissions on its contents.

If you have a directory, it is possible to change permissions recursively: One command can apply permissions to the directory and all of its contents, including sub-directories, their contents, etc…. However, as before, ownership still matters: Even if you run a recursive permissions-change, you can only change the permissions of items that you own.

The process for changing permissions is different for basic permissions and for ACLs. Each one will be covered separately.

Changing Basic Permissions¶

The command to change basic permissions is chmod. To change permissions on a single file, it uses this form:

chmod MODE ITEM

To resursively change permissions on a directory and all of its contnets, it uses this form:

chmod -R MODE DIRECTORY

The MODE section is where you specify the permissions change you want to make. You can specify changes in octal or human-readable form.

If you specify permissions in octal form, the current permissions will be overwritten by what you set. For example, to change a file to be read+write+execute by its current owner, and read-only for everyone else, you would run chmod 0744 ITEM.

If you specify permissions in human-readable form, you can modify or overwrite permissions. In human-readable form, the MODE is a string which looks something like this:

ugo+rwx

The string has three parts:

• The first part says if you want to change permissions for the Owning User (u), Owning Group (g), others (o), or everyone (a). Letters can be combined: For example, ug means “the Owning User and the Owning Group”.

• Next, you say if you want to add (+) or remove (-) permissions, or set completely-new permissions (=). You can only use one letter here.

• Finally, you give the permissions: read (r), write (w), execute (x), or setgid (s). You can also use X, which means “x if the item is a directory or it is already executable”. Letters can also be combined here: For example, rw means “read+write”. If you leave this part blank, it means “no permissions”.

If you want to have multiple mode strings, separate them with a comma.

Here are some examples of mode strings:

• a+x: Add execute permissions for everyone. This is something you might use for a new script or program.

• go-w: Remove write permissions from the Owning Group and other users. The Owning User’s permissions are not changed.

• o=: Remove all permissions from others. The permissions for the Owning User and Owning Group are not changed.

• a=r,u+w: Change everyone’s permissions to read-only, then give the Owning User write access.

• g+rwx,o= No changes to the Owning User, add read+write+execute for the Owning Group, and remove permissions for other users.

Here is an example of using chmod with an octal MODE to give read+write to the Owning User, and read to everyone else; then using chmod with a human-readable MODE to give write permissions to the Owning Group:

[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ chmod 0644 x
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ ls -l x
-rw-r--r-- 1 akkornel scg_lab_ruthm 0 Dec 13 20:31 x
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ chmod g+w x
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ ls -l x
-rw-rw-r-- 1 akkornel scg_lab_ruthm 0 Dec 13 20:31 x

Note how the above example does not show the permissions before the first chmod command: Since the chmod command with an octal MODE overwrites the item’s permissions, it doesn’t matter what the permissions used to be.

Finally, here is an example of changing permissions recursively:

[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ ls -ld d
drwxrwsr-x 2 akkornel scg_lab_ruthm 4096 Dec 13 20:43 d
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ ls -l d
total 0
-rw-rw-r-- 1 akkornel scg_lab_ruthm 0 Dec 13 20:43 a
-rw-rw-r-- 1 akkornel scg_lab_ruthm 0 Dec 13 20:43 b
-rw-rw-r-- 1 akkornel scg_lab_ruthm 0 Dec 13 20:43 c
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ chmod -R o= d
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ ls -ld d
drwxrws--- 2 akkornel scg_lab_ruthm 4096 Dec 13 20:43 d
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ ls -l d
total 0
-rw-rw---- 1 akkornel scg_lab_ruthm 0 Dec 13 20:43 a
-rw-rw---- 1 akkornel scg_lab_ruthm 0 Dec 13 20:43 b
-rw-rw---- 1 akkornel scg_lab_ruthm 0 Dec 13 20:43 c

In this example, a directory containing three files has other-user access removed by using a single execution of chmod.

Changing ACLs¶

The command to change ACLs is setfacl. The command does different things, depending on the options you provide.

Setting ACLs¶

TODO

Removing individual ACLs¶

TODO

Deleting complete ACLs¶

If you want to remove an ACL completely, use the -b option to setfacl, like this:

[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ getfacl d
# file: d
# owner: akkornel
# group: scg_lab_ruthm
# flags: -s-
user::rwx
group::r-x
mask::rwx
other::---
default:user::rwx
default:user:melchua:rw-
default:group::r-x
default:mask::rwx
default:other::---
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ setfacl -b d
[akkornel@smsh11dsu-srcf-d15-36 akkornel]$ getfacl d
# file: d
# owner: akkornel
# group: scg_lab_ruthm
# flags: -s-
user::rwx
group::r-x
other::---

In the above example, setfacl -b d removed the ACL from directory d. Directory d now uses Basic Permissions only.

This change can be done recursively, using the -R option. For example, if d is a directory, running setfacl -b -R d will remove the ACL from directory d, and also remove the ACLs from everything that is inside directory d.

Using chmod on items with ACLs¶

If you want to change any of the flags for a directory—such as the setgid flag—you can do so with chmod:

[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ getfacl d
# file: d               ──┐
# owner: akkornel         │
# group: scg_lab_ruthm    │  No flags field, because
user::rwx                 ├─▶no flags are set.
group::r-x                │
other::---              ──┘

[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ chmod g+s d
[akkornel@smsh11dsu-srcf-d15-37 akkornel]$ getfacl d
# file: d
# owner: akkornel
# group: scg_lab_ruthm       Flags field appears after
# flags: -s-  ──────────────▶setting at least one flag.
user::rwx
group::r-x
other::---

Since ACLs are more complex than Basic Permissions, and chmod only recognizes basic permissions, the system must translate your chmod into ACLs. Here is how a chmod permissions change is applied to ACLs:

• If you use chmod to change the permissions for the Owning User, those changes will apply as you expect.

• If you use chmod to change the permissions for other users, those changes will apply as you expect.

• If you use chmod to change the permissions for the Owning Group, those changes will be applied to the mask.

Here is an example of how chmod affects the Owning User and other users:

[akkornel@smsh11dsu-srcf-d15-37 d]$ getfacl b
# file: b
# owner: akkornel
# group: scg_lab_ruthm
user::rw-         ─────┐
user:melchua:rw-       │
group::rw-             ├─────▶Everyone has write permission
mask::rw-              │
other::rw-        ─────┘
[akkornel@smsh11dsu-srcf-d15-37 d]$ chmod uo-w b
[akkornel@smsh11dsu-srcf-d15-37 d]$ getfacl b
# file: b
# owner: akkornel
# group: scg_lab_ruthm
user::r--  ───────┐       Owning User write permission
user:melchua:rw-  └──────▶removed as expected
group::rw-
mask::rw-                 Others write permission
other::r--  ─────────────▶removed as expected

Next, here is an example showing how, when using chmod to change group access, the change is applied to the mask:

[akkornel@smsh11dsu-srcf-d15-37 d]$ getfacl b
# file: b
# owner: akkornel
# group: scg_lab_ruthm
user::rw-         ───────┐
user:melchua:rw-         │
group::rw-               ├──────▶Everyone has write permission
mask::rw-                │
other::rw-        ───────┘

[akkornel@smsh11dsu-srcf-d15-37 d]$ chmod g-w b
[akkornel@smsh11dsu-srcf-d15-37 d]$ getfacl b
# file: b
# owner: akkornel                          Named User no longer
# group: scg_lab_ruthm            ┌───────▶has write access.
user::rw-                         │
user:melchua:rw-        #effective:r--
group::rw-          #effective:r--
mask::r--  ────┐              │            Owning Group no longer
other::rw-     │              └───────────▶has write access.
               │
               └────▶`chmod` of group permissions applied to mask

Because using chmod to change group permissions is applied to the mask, you might want to be careful when using chmod with files that have ACLs.

Example ACLs for Labs¶

TODO