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, 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 fin-grain control than ug:s bits of chmod.
• chattr Allows some other controls(a bit of a mix) of 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 the 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 to 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 bit is to be modified:

  • r read
  • w write
  • x execute (or search for directories)
  • X execute/search only if the file is a directory or already has execute bit set for some user
  • 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), member's of the file's group (g) or permissions of 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/cross (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 edited (files added, deleted, renamed).
    • Execute (x) affects if a file can be run, use for scripts (see #!), and other executable files.
    • Cross (x) affects if a directory can be traversed.
  • s and t — sticky bit (t), and setgid (s) on directories
    • The sticky bit only affects directories. Will prevent any one 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 there 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 effective user/group of the executable will become that of the file. 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 acdeijstuADST, which correspond the attributes:

• a append only
• c compressed
• d no dump
• e extent format
• i immutable
• j data journalling
• s secure deletion
• t no tail-merging
• u undeletable
• A no atime updates
• D synchronous directory updates
• S synchronous updates
• T top of directory hierarchy

---

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 form 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 uid 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

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 filesystem 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 computer 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 permanently 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.
• SELINUX known as secure linux. You can web search the history on it. Also know there are alternatives to SELINUX such as AppArmor, and there are 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 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 1960's)
• it's really just the inherent basic file/folder permissions with uid's/gid's plus xattr's that makes everything possible; SELinux uses xattr's to store file/folder security labels... with selinux all the low level legwork is somewhat done/defined in xattr's 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, may be able to enable or disable xattr's 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 root file system at install time; i think now with RHEL/CentOS 7 that xattr is there by default and you can't not have it.
• when doing an ls 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 centos wiki 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 xattr's 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 a [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 xattr's are important (i.e. samba and copying between win10 ntfs and linux ext3/4,btrfs,xfs; or back and forth between network attached storage devices)
• if there is no selinux or other mechanisam 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 lables 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 denied 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:

# this is an selinux command, not 
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 win10 pc 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 there heads wondering why things just worked 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.