STANDARD INPUT

None.

INPUT FILES

None.

ENVIRONMENT VARIABLES

The following environment variables shall affect the execution of chmod:

LANG

This variable shall determine the locale to use for the locale categories when both LC_ALL and the corresponding environment variable (beginning with LC_ ) do not specify a locale. See 2.6.

LC_ALL

This variable shall determine the locale to be used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_.

LC_CTYPE

This variable shall determine the locale for the interpretation of sequences of bytes of text data as characters (e.g., single- versus multibyte characters in arguments).

LC_MESSAGES

This variable shall determine the language in which messages should be written.

ASYNCHRONOUS EVENTS

Default.

STANDARD OUTPUT

None.

STANDARD ERROR

Used only for diagnostic messages.

OUTPUT FILES

None.

CHMOD GRAMMAR

The grammar and lexical conventions in this subclause describe the syntax for the symbolic_mode operand. The general conventions for this style of grammar are described in 2.1.2. A valid symbolic_mode can be represented as the nonterminal symbol symbolic_mode in the grammar. Any discrepancies found between this grammar and descriptions in the rest of this clause shall be resolved in favor of this grammar. The lexical processing shall be based entirely on single characters. Implementations need not allow <blank>s within the single argument being processed.

%start symbolic_mode %% symbolic_mode : clause

; clause : actionlist

; wholist : who

; who : ’u’

; actionlist : action

; action : op

;

permcopy : ’u’

; op : ’+’

; permlist : perm

; perm : ’r’

;

EXAMPLES

The functionality of chmod is described substantially through references to concepts defined in POSIX. 1 {8}. In this way, there is less duplication of effort required for describing the interactions of permissions, etc. However, the behavior of this utility is not described in terms of the chmod function from POSIX. 1 {8}, because that specification requires certain side effects upon alternate file access control mechanisms that might not be appropriate, depending on the implementation. Some historical implementations of the chmod utility change the mode of a directory before the files in the directory when performing a recursive (−R option)

change; others change the directory mode after the files in the directory. If an application tries to remove read or search permission for a file hierarchy, the removal attempt will fail if the directory is changed first; on the other hand, trying to re-enable permissions to a restricted hierarchy will fail if directories are changed last. Since neither method is clearly better and users do not frequently try to make a hierarchy inaccessible to themselves, the standard does not specify what happens in this case. Note that although the association shown in the table between bits in the octal number and the indicated file mode bits must be supported, this does not require that a conforming implementation has to actually use those octal values to implement the macros shown. Historical System V implementations of chmod never use the process’s umask when changing modes. Version 7 and historical BSD systems do use the mask when who is not specified, as described in this standard. Applications should note the difference between: chmod a-w file which removes all write permissions, and: chmod -- -w file which removes write permissions that would be allowed if file was created with the same umask. Note that mode operands −r, −w, −s, −x, or −X, or anything beginning with a hyphen, must be preceded by -- to keep it from being interpreted as an option. It is difficult to express the grammar used by chmod in English, but the following examples have been accepted by historical System V and BSD systems and are, therefore, required to behave this way by POSIX. 2 even though some of them could be expressed more succinctly:

Mode

Results a+= Equivalent to a+,a=; clears all file mode bits. go+-w Equivalent to go+,go-w; clears group and other write bits. g=o-w Equivalent to g=o,g-w; sets group bit to match other bits and then clears group write bit. g-r+w Equivalent to g-r,g+w; clears group read bit and sets group write bit. =g Sets owner bits to match group bits and sets other bits to match group bits.

HISTORY OF DECISIONS MADE

Implementations that support mandatory file and record locking as specified by the /usr/group Standard B29 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 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 standard does not require mandatory locking (nor does POSIX. 1 {8}), but does allow it as an extension. However, POSIX. 2 does require that the ls and chmod utilities work consistently in this area. If ls -l file says 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. A ‘‘sticky’’ file mode bit, indicating that the text portion of an executable object program file should be saved after the program is gone, has meaning in some implementations, but was omitted here because its purpose is implementation dependent and because it was omitted from POSIX. 1 {8}. On bc(1) BSD-based implementations, the sticky bit is used in conjunction with directory permissions to keep anyone from deleting a file that they do not own from the directory. The perm symbol t is used to represent the sticky bit in many existing implementations and should not be used for other conflicting extensions. POSIX. 1 {8} indicates that implementation-defined restrictions may cause the S_ISUID and S_ISGID bits to be ignored. POSIX. 2 allows the chmod utility to choose to modify these bits before calling POSIX. 1 {8} chmod (or some function providing equivalent capabilities) for nonregular 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. Portable applications should never assume that they know how these bits will be interpreted, except on regular files. The grammar in Draft 9 did not allow several symbolic mode operands that are correctly processed by historical implementations. (It only allowed two clauses and one op per clause.) The grammar presented in Draft 10 matches historical implementations. The X perm symbol was added, as provided in 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 here 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 nonterminal to allow existingpractice forms of symbolic modes like o=u-g (i.e., set the ‘‘other’’ permissions to the permissions of ‘‘owner’’ minus the permissions of ‘‘group’’.)