---

   chmod.1p    ( 1 )

---

Обоснование (Rationale)

The functionality of chmod is described substantially through
       references to concepts defined in the System Interfaces volume of
       POSIX.1‐2017. In this way, there is less duplication of effort
       required for describing the interactions of permissions. However,
       the behavior of this utility is not described in terms of the
       chmod() function from the System Interfaces volume of
       POSIX.1‐2017 because that specification requires certain side-
       effects upon alternate file access control mechanisms that might
       not be appropriate, depending on the implementation.

       Implementations that support mandatory file and record locking as
       specified by the 1984 /usr/group standard historically used the
       combination of set-group-ID bit set and group execute bit clear
       to indicate mandatory locking. This condition is usually set or
       cleared with the symbolic mode perm symbol l instead of the perm
       symbols s and x so that the mandatory locking mode is not changed
       without explicit indication that that was what the user intended.
       Therefore, the details on how the implementation treats these
       conditions must be defined in the documentation. This volume of
       POSIX.1‐2017 does not require mandatory locking (nor does the
       System Interfaces volume of POSIX.1‐2017), but does allow it as
       an extension. However, this volume of POSIX.1‐2017 does require
       that the ls and chmod utilities work consistently in this area.
       If ls -l file indicates that the set-group-ID bit is set, chmod
       g-s file must clear it (assuming appropriate privileges exist to
       change modes).

       The System V and BSD versions use different exit status codes.
       Some implementations used the exit status as a count of the
       number of errors that occurred; this practice is unworkable since
       it can overflow the range of valid exit status values. This
       problem is avoided here by specifying only 0 and >0 as exit
       values.

       The System Interfaces volume of POSIX.1‐2017 indicates that
       implementation-defined restrictions may cause the S_ISUID and
       S_ISGID bits to be ignored. This volume of POSIX.1‐2017 allows
       the chmod utility to choose to modify these bits before calling
       chmod() (or some function providing equivalent capabilities) for
       non-regular files. Among other things, this allows
       implementations that use the set-user-ID and set-group-ID bits on
       directories to enable extended features to handle these
       extensions in an intelligent manner.

       The X perm symbol was adopted from BSD-based systems because it
       provides commonly desired functionality when doing recursive (-R
       option) modifications. Similar functionality is not provided by
       the find utility. Historical BSD versions of chmod, however, only
       supported X with op+; it has been extended in this volume of
       POSIX.1‐2017 because it is also useful with op=.  (It has also
       been added for op- even though it duplicates x, in this case,
       because it is intuitive and easier to explain.)

       The grammar was extended with the permcopy non-terminal to allow
       historical-practice forms of symbolic modes like o=u -g (that is,
       set the ``other'' permissions to the permissions of ``owner''
       minus the permissions of ``group'').