What are the different ways to set file permissions, etc., on GNU/Linux?

Question

On Unix, a long time back, I learned about chmod: the traditional way to set permissions on Unix (and to allow programs to gain privileges, using setuid and setgid).

I have recently discovered some newer commands on GNU/Linux:

• setfacl extends the traditional ugo:rwx bits and the t bit of chmod.
• setcap gives more fine-grained control over privileges than the ug:s bits of chmod.
• chattr allows some other controls (a bit of a mix) over the file.

Are there any others?

Answer 1

chmod: change file mode bits

Usage (octal mode):

chmod octal-mode files...

Usage (symbolic mode):

chmod [references][[operator][modes]] files...

references is a combination of the letters ugoa, which specify which user's access to the files will be modified:

• u the user who owns it
• g other users in the file's group
• o other users not in the file's group
• a all users

If omitted, it defaults to all users, but only permissions allowed by the umask are modified.

operator is one of the characters +-=:

• + add the specified file mode bits to the existing file mode bits of each file
• - removes the specified file mode bits from the existing file mode bits of each file
• = adds the specified bits and removes unspecified bits, except the setuid and setgid bits set for directories, unless explicitly specified.

mode consists of a combination of the letters rwxXst, which specify which permission bits are to be modified:

• r read
• w write
• x (lower case X) execute (or search for directories)
• X (capital) execute/traverse only if the file is a directory or already has an execute bit set for some user category
• s setuid or setgid (depending on the specified references)
• t restricted deletion flag or sticky bit

Alternatively, the mode can consist of one of the letters ugo, in which case case the mode corresponds to the permissions currently granted to the owner (u), members of the file's group (g) or users in neither of the preceding categories (o).

The various bits of chmod explained:

• Access control (see also setfacl)
  • rwx — read (r), write (w), and execute/traverse (x) permissions
    • Read (r) affects if a file can be read, or if a directory can be listed.
    • Write (w) affects if a file can be written to, or if a directory can be modified (files added, deleted, renamed).
    • Execute (x) affects if a file can be run, use for scripts and other executable files.
    • Traverse (x), also known as "search", affects whether a directory can be traversed; i.e., whether a process can access (or try to access) file system objects through entries in this directory.
  • s and t — sticky bit (t), and setgid (s) on directories
    • The sticky bit only affects directories. Will prevent anyone except file owner, and root, from deleting files in the directory.
    • The setgid bit on directories will cause new files and directories to have the group set to the same group, and new directories to have their setgid bit set (see also defaults in setfacl).
  • s — setuid, setgid, on executable files
    • This can affect security in a bad way, if you don't know what you are doing.
    • When an executable is run, if one of these bits is set, then the user/group of the executable will become the effective user/group of the process.  Thus the program runs as that user.  See setcap for a more modern way to do this.

---

chown chgrp:

---

chattr: change file attributes

Usage:

chattr operator[attribute] files...

operator is one of the characters +-=:

• + adds the selected attributes to be to the existing attributes of the files
• - removes the selected attributes
• = overwrites the current set of attributes the files have with the specified attributes.

attribute is a combination of the letters acdeijmstuxACDFPST, which correspond to the attributes:

• a append only
• c compressed
• d no dump
• e extent format
• i immutable
• j data journaling
• m don't compress
• s secure deletion
• t no tail-merging
• u undeletable
• x direct access for files
• A no atime updates
• C no copy on write
• D synchronous directory updates
• F case-insensitive directory lookups
• P project hierarchy
• S synchronous updates
• T top of directory hierarchy

There are restrictions on the use of many of these attributes.  For example, many of them can be set or cleared only by the superuser (i.e., root) or an otherwise privileged process.

---

setfattr: change extended file attributes

Usage (set attribute):

setfattr -n name -v value files...

Usage (remove):

setfattr -x name files...

name is the name of the extended attribute to set or remove

value is the new value of the extended attribute

---

setfacl: change file access control lists

Usage:

setfacl option [default:][target:][param][:perms] files...

option must include one of the following:

• --set set the ACL of a file or a directory, replacing the previous ACL
• -m|--modify modify the ACL of a file or directory
• -x|--remove remove ACL entries of a file or directory

target is one of the letters ugmo (or the longer forms shown below):

• u, users permission of a named user identified by param, defaults to file owner UID if omitted
• g, group permission of a named group identified by param, default to owning group GID if omitted
• m, mask effective rights mask
• o, other permissions of others

perms is a combination of the letters rwxX, which correspond to the permissions:

• r read
• w write
• x execute
• X execute only if the file is a directory or already has execute permission for some user

Alternatively, perms may be an octal digit (0-7) indicating the set of permissions.

---

setcap: change file capabilities

Usage:

setcap capability-clause file

A capability-clause consists of a comma-separated list of capability names followed by a list of operator-flag pairs.

The available operators are =, + and -. The available flags are e, i and p which correspond to the Effective, Inheritable and Permitted capability sets.

The = operator will raise the specified capability sets and reset the others. If no flags are given in conjunction with the = operator all the capability sets will be reset. The + and - operators will raise or lower the one or more specified capability sets respectively.

---

chcon: change file SELinux security context

Usage:

chcon [-u user] [-r role] [-t type] files...

user is the SELinux user, such as user_u, system_u or root.

role is the SELinux role (always object_r for files)

type is the SELinux subject type

---

chsmack: change SMACK extended attributes

SMACK is Simplified Mandatory Access Control Kernel.

Usage:

chsmack -a value file

value is the SMACK label to be set for the SMACK64 extended file attribute

---

setrichacl: change rich access control list

richacls are a feature that will add more advanced ACLs.

Currently a work in progress, so I can not tell you much about them. I have not used them.

See also this question Are there more advanced filesystem ACLs beyond traditional 'rwx' and POSIX ACL? and man page

Answer 2

From a high level:

• Basic file system permissions supported by all Linux and all Unix-friendly filesystems which is the -rwxrwxrwx handled by chmod, along with owner and group identifiers tied to every file or folder on the filesystem handled by chown and chgrp; everyone basically knows this piece.
• Extended File Attributes, which is abbreviated or known by xattr.  They are file system features that enable users to associate files with metadata not interpreted by the filesystem, whereas regular attributes have a purpose strictly defined by the filesystem; the attributes are name:value pairs associated with files and directories, similar to the environment strings associated with a process.  There are specific Linux commands related to simply setting this metadata to various files/folders.
• Security-Enhanced Linux (commonly known as SELinux).   See selinuxproject.org and Wikipedia.  Also know there are alternatives to SELinux such as AppArmor, and probably others.  At this point, these are kernel modules that provide functionality and mechanisms for doing MAC (mandatory access control) by making use of xattr; SELinux stores file security labels in xattrs.  And there are specific SELinux-related commands.

Other key points:

• The era and version of GNU/Linux matters regarding xattr and SELinux for what is available and what is functional.

• It is reported that not all file systems support xattr; best left to individual research based on the distribution and version of Linux being used (RHEL/SUSE/Debian, IRIX, Solaris, AIX, Unix from the 1960s).

• It's really just the inherent basic file/folder permissions with UIDs/GIDs plus xattrs that makes everything possible; SELinux uses xattrs to store file/folder security labels... with SELinux all the low-level legwork is somewhat done/defined in xattrs for you to make use of.  So if your ancient file system does not support xattr, you won't be using SELinux.

• You can enable or disable SELinux (or AppArmor or any other kernel module).

• Depending on your version of Linux, you may be able to enable or disable xattrs for a given mounted file system; I remember in SLES 11 the fstab mount option of user_xattr and I could choose to not have xattr available on the root file system at install time; I think now with RHEL/CentOS 7 that xattr is there by default and you can't remove it.

• When doing an ls -l, if you see -rwxrwxrwx+, that + indicates an extended file attribute is present on that object.

• Access Control List (ACL) is a list of permissions attached to an object.  An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects.

• From the CentOS Wiki article on SELinux:

  SELinux is a MAC security mechanism implemented in the kernel.  ...  Without SELinux enabled, only traditional discretionary access control (DAC) methods such as file permissions or access control lists (ACLs) are used to control the file access of users.  Users and programs alike are allowed to grant insecure file permissions to others or, conversely, to gain access to parts of the system that should not otherwise be necessary for normal operation.  ...  Essentially under the traditional DAC model, there are two privilege levels, root and user, and no easy way to enforce a model of least-privilege.  Many processes that are launched by root later drop their rights to run as a restricted user ...

  worth the read to put the use of xattrs and ACLs in perspective, because Linux [kernel] treats everything as a file (block devices or network ports) you can tag almost anything with an xattr and enforce some kind of access control via SELinux; it's not just files/folders. https://wiki.centos.org/HowTos/SELinux

• xattr can cause problems with moving data between systems and file systems, and NFS, where [newer] systems having fuller support of xattr versus older systems which might not recognize all these extended attributes [if at all].  Be mindful of using tar on stuff with xattr; if it stays on that system no problem but if it goes elsewhere can be problematic if the xattrs are important (e.g., Samba and copying between Windows 10 NTFS and Linux ext3/4, btrfs, XFS; or back and forth between network attached storage (NAS) devices).

• If there is no SELinux or other mechanism enforcing ACLs by what is defined in xattrs, then xattrs can theoretically mean nothing and be dropped or stripped, because at that point it's just extra baggage.

• Be careful disabling SELinux now in RHEL/CentOS 7 because if file system labels via xattr are lost it will cause problems when changing SELinux back to enforcing or permissive; again it depends on your version of Linux and how it is making use of xattr via SELinux.

Basic Samba share not working in RHEL/CentOS 7... because SELinux by default is set to enforcing; SELinux denies everything until you allow it, so either disable SELinux (bad) or set it to permissive. If you leave SELinux as enforcing, then you have to label the folder you want to Samba share out with an extended attribute, so SELinux will recognize and allow the share. So if you leave SELinux enforcing then with all SELinux commands (which will then set the necessary xattrs):

# from CentOS 7.6 /etc/samba/smb.conf.example

# Turn the samba_domain_controller Boolean on to allow a Samba PDC to use
# the useradd and groupadd family of binaries.
# Run the following command as the root user to turn this Boolean on:

setsebool -P samba_domain_controller on

# If you create a new directory, such as a new top-level directory, label it
# with samba_share_t so that SELinux allows Samba to read and write to it.
# Do not label system directories, such as /etc/ and /home/, with samba_share_t,
# as such directories should already have an SELinux label.


# the xattr having the name "samba_share_t" is labelled onto "/mydatashare"
# this xattr of syntax "samba_share_t" is recognized by an existing rule in SELinux
# if the folder does not have the xattr "samba_share_t" then the rule in SELinux
# (when enforced) will prevent access via Samba to the folder.

chcon -t samba_share_t /mydatashare

You further use SELinux, on the Linux system with this Samba share, to enforce restrictions on files/folders under this Samba share (using whatever extended attribute).  Because these files/folders are shared out, a user legitimately copies some to their Windows 10 PC and then copies back, losing the extended attribute.  Now after that back and forth copy, on that Linux system SELinux will restrict access to said files because the necessary xattr is no longer present, and users/admins bang their heads wondering why something just worked and now it doesn't...  Set SELinux to permissive and recognize the problem of lost xattrs showing up in the audit logs but it won't directly indicate it was a result of the back and forth copy losing the xattr.  Also consider data backup and restoration, and potential work needed to remember xattrs in addition to UID/GID if you want to enforce security based on the correct xattrs.

Answer 3

I highly recommend chmod

$ chmod [Options] [Filename]

$ chmod [Option1] [Operator] [Option2] [Filename]

---

In numerical representation, we have these options:

“0” represents “no permission”

“1” represents “execute permission”

“2” represents “write permission”

“4” represents “read permission”

options in the symbolic form:

“u” indicates file owner

“g” indicates groups

“o” indicates others

“a” indicates all users as owner, group, and others (ugo)

Whereas the chmod command accepts the following operators:

“+”: This operator is utilized to add specified permissions

“–”: This operator is utilized to remove specified permissions

“=”: This operator is utilized to define the exact file permission for any user.