Linux etc permissions file

chmod : change file mode bits

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.
    • 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 ).
    • 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

    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

    setfattr -n name -v value files. 

    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

    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

    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

    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.

    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.

    +1 If you added examples of each cmd’s usage, this answer would be extremely useful, as a canonical answer we can reference down the road!

    A warning to any one wishing to take capabilities further than shown here. I have used capability as outlined here. However trying to inherit them (usefully) over fork and exec seems impossible. I think there is a bug see unix.stackexchange.com/questions/196483/…

    The bug I mentioned in previous coment, it was a design bug and was fixed in kernel 4.3 with the addition of ambient capabilities, see man7.org/linux/man-pages/man7/capabilities.7.html

    • 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.
    • 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 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, you 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 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 .

    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 xattr s):

    # 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 xattr s 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 xattr s in addition to UID/GID if you want to enforce security based on the correct xattr s.

    Источник

    Читайте также:  Расширение файла скрипта linux