chmod(1) User Commands chmod(1)NAMEchmod - change the permissions mode of a file
SYNOPSISchmod [-fR] absolute-mode file...
chmod [-fR] symbolic-mode-list file...
chmod [-fR] acl_operation file...
DESCRIPTION
The chmod utility changes or assigns the mode of a file.
chmod can also be used to modify Access Control Lists (ACLs) on files
and directories.
Absolute Mode
An absolute mode specification has the following format:
chmod [options] absolute-mode file . . .
where absolute-mode is specified using octal numbers nnnn defined as
follows:
n a number from 0 to 7. An absolute mode is constructed from the OR
of any of the following modes:
4000 Set user ID on execution.
20#0 Set group ID on execution if # is 7, 5, 3, or 1.
Enable mandatory locking if # is 6, 4, 2, or 0.
For directories, files are created with BSD semantics
for propagation of the group ID. With this option,
files and subdirectories created in the directory
inherit the group ID of the directory, rather than of
the current process. For directories, the set-gid bit
can only be set or cleared by using symbolic mode.
1000 Turn on sticky bit. See chmod(2).
0400 Allow read by owner.
0200 Allow write by owner.
0100 Allow execute (search in directory) by owner.
0700 Allow read, write, and execute (search) by owner.
0040 Allow read by group.
0020 Allow write by group.
0010 Allow execute (search in directory) by group.
0070 Allow read, write, and execute (search) by group.
0004 Allow read by others.
0002 Allow write by others.
0001 Allow execute (search in directory) by others.
0007 Allow read, write, and execute (search) by others.
For directories, the setgid bit cannot be set (or cleared) in absolute
mode; it must be set (or cleared) in symbolic mode using g+s (or g-s).
Symbolic Mode
A symbolic mode specification has the following format:
chmod [options] symbolic-mode-list file . . .
where symbolic-mode-list is a comma-separated list (with no intervening
whitespace) of symbolic mode expressions of the form:
[who] operator [permissions]
Operations are performed in the order given. Multiple permissions let‐
ters following a single operator cause the corresponding operations to
be performed simultaneously.
who zero or more of the characters u, g, o, and a specifying
whose permissions are to be changed or assigned:
u user's permissions
g group's permissions
o others' permissions
a all permissions (user, group, and other)
If who is omitted, it defaults to a, but the setting of
the file mode creation mask (see umask in sh(1) or csh(1)
for more information) is taken into account. When who is
omitted, chmod does not override the restrictions of your
user mask.
operator either +, −, or =, signifying how permissions are to be
changed:
+ Add permissions.
If permissions are omitted, nothing is added.
If who is omitted, add the file mode bits repre‐
sented by permissions, except for the those with
corresponding bits in the file mode creation
mask.
If who is present, add the file mode bits repre‐
sented by the permissions.
− Take away permissions.
If permissions are omitted, do nothing.
If who is omitted, clear the file mode bits rep‐
resented by permissions, except for those with
corresponding bits in the file mode creation
mask.
If who is present, clear the file mode bits rep‐
resented by permissions.
= Assign permissions absolutely.
If who is omitted, clear all file mode bits; if
who is present, clear the file mode bits repre‐
sented by who.
If permissions are omitted, do nothing else.
If who is omitted, add the file mode bits repre‐
sented by permissions, except for the those with
corresponding bits in the file mode creation
mask.
If who is present, add the file mode bits repre‐
sented by permissions.
Unlike other symbolic operations, = has an absolute
effect in that it resets all other bits represented by
who. Omitting permissions is useful only with = to take
away all permissions.
permission any compatible combination of the following letters:
l mandatory locking
r read permission
s user or group set-ID
t sticky bit
w write permission
x execute permission
X execute permission if the file is a directory or
if there is execute permission for one of the
other user classes
u,g,o indicate that permission is to be taken from the
current user, group or other mode respectively.
Permissions to a file can vary depending on your user
identification number (UID) or group identification num‐
ber (GID). Permissions are described in three sequences
each having three characters:
User Group Other
rwx rwx rwx
This example (user, group, and others all have permission
to read, write, and execute a given file) demonstrates
two categories for granting permissions: the access class
and the permissions themselves.
The letter s is only meaningful with u or g, and t only
works with u.
Mandatory file and record locking (l) refers to a file's
ability to have its reading or writing permissions locked
while a program is accessing that file.
In a directory which has the set-group-ID bit set
(reflected as either -----s--- or -----l--- in the output
of 'ls -ld'), files and subdirectories are created with
the group-ID of the parent directory—not that of current
process.
It is not possible to permit group execution and enable a
file to be locked on execution at the same time. In addi‐
tion, it is not possible to turn on the set-group-ID bit
and enable a file to be locked on execution at the same
time. The following examples, therefore, are invalid and
elicit error messages:
chmod g+x,+l file
chmod g+s,+l file
Only the owner of a file or directory (or the super-user)
can change that file's or directory's mode. Only the
super-user can set the sticky bit on a non-directory
file. If you are not super-user, chmod masks the sticky-
bit but does not return an error. In order to turn on a
file's set-group-ID bit, your own group ID must corre‐
spond to the file's and group execution must be set.
ACL Operation
An ACL Operation specification has the following format:
chmod [options] A[number]- file ...
chmod [options] A-acl_specification file ...
chmod [options] A[index]{+|=}acl_specification file ...
Where acl_specification is a comma-separated list (with no intervening
whitespace) of an ACL specification of the form:
A[index]+acl_specification Prepends the access control entries (ACE)
specified in acl_specification to the
beginning of the file's ACL. Depending on
the file system, the ACL can be reordered
when applied to the file. If "optional"
number is specified then new ACEs are
inserted before specified number.
A- Removes all ACEs for current ACL on file
and replaces current ACL with new ACL
that represents only the current mode of
the file.
Aindex- Removes ACE specified by index number.
A-acl_specification Removes ACEs specified by acl_specifica‐
tion, if they exist in current file's
ACL.
A=acl_specification Replaces a files entire ACL with
acl_specification.
A[index]=acl_specification Replaces ACEs starting at a specific
index number in the current ACL on the
file. If multiple ACEs are specified,
then each subsequent ACE in acl_specifi‐
cation replaces the corresponding ACE in
the current ACL.
POSIX-draft ACL Specification (as supported by UFS)
POSIX-draft ACLs (as supported by UFS) are specified as colon (:) sepa‐
rated fields of the following.
user::perms
File owner permissions.
user:username:perms
Permissions for a specific user.
group::perms
File group owner permissions.
group:groupname:perms
Permissions for a specific group.
other::perms
Permissions for user other than the file owner or members of file
group owner.
mask:perms
The ACL mask. The mask entry specifies the maximum permissions
allowed for user (other than that the owner) and for groups.
default:user::perms
Default file owner permissions.
default:user:username:perms
Default permissions for a specific user.
default:group::perms
Default file group owner permissions.
default:group:groupname:perms
Default permissions for a specific group.
default:other:perms
Default permissions for user other than the file owner or members
of the file group owner.
default:mask:perms
Default ACL mask.
The above specification allows for ACLs to be specified such as:
user:tom:rw-,mask:rwx,group:staff:r-x
NFSv4 ACL Specification (as supported by NFSv4 and ZFS)
NFSv4 ACLs provide richer ACL semantics. They provide both allow and
deny entries, finer grained permissions, and enhanced inheritance con‐
trol.
NFSv4 ACLs are specified as colon (:) separated fields of the follow‐
ing.
owner@:<perms>[:inheritance flags]:<allow|deny>
Permissions for file owner.
group@:<perms>[:inheritance flags]:<allow|deny>
Permissions for file group owner.
everyone@:<perms>[:inheritance flags]:<allow|deny>
Permissions for everyone, including file owner and group owner.
user:<username>:<perms>[:inheritance flags]:<allow|deny>
Permissions for a specific user.
group:<groupname>:<perms>[:inheritance flags]:<allow|deny>
Permissions for a specific group.
groupsid:<sid string>:<perms>[:inheritance flags]:<allow|deny>
Permissions for a specific group, but group is specified by SID.
sid:<sid string>:<perms>[:inheritance flags]:<allow|deny>
Permissions for a specific SID, but it doesn't matter if it is a
user or a group.
Permissions can be specified in three different chmod ACL formats:
verbose, compact, or positional. The verbose format uses words to
indicate that the permissions are separated with a forward slash (/)
character. Compact format uses the permission letters and positional
format uses the permission letters or the hyphen (-) to identify no
permissions.
The permissions for verbose mode and their abbreviated form in paren‐
theses for compact and positional mode are described as follows:
read_data (r) Permission to read the data of a file.
list_directory (r) Permission to list the contents of a directory.
write_data (w) Permission to modify a file's data. anywhere in
the file's offset range.
add_file (w) Permission to add a new file to a directory.
append_data (p) The ability to modify a file's data, but only
starting at EOF.
Currently, this permission is not supported.
add_subdirectory (p) Permission to create a subdirectory to a direc‐
tory.
read_xattr (R) Ability to read the extended attributes of a
file.
write_xattr (A) Ability to create extended attributes or write
to the extended attribute directory.
execute (x) Permission to execute a file.
read_attributes (a) The ability to read basic attributes (non-ACLs)
of a file.
write_attributes (W) Permission to change the times associated with
a file or directory to an arbitrary value.
delete (d) Permission to delete a file.
For more information about delete permission
behavior, see the Oracle Solaris ZFS Adminis‐
tration Guide.
delete_child (D) Permission to delete a file within a directory.
For more information about delete permission
behavior, see the Oracle Solaris ZFS Adminis‐
tration Guide.
read_acl (c) Permission to read the ACL of a file.
write_acl (C) Permission to write the ACL of a file.
write_owner (o) Permission to change the owner of a file.
synchronize (s) Permission to access file locally at server
with synchronize reads and writes.
Currently, this permission is not supported.
Using the compact ACL format, permissions are specified by using 14
unique letters to indicate permissions.
Using the positional ACL format, permissions are specified as posi‐
tional arguments similar to the ls -V format. The hyphen (-), which
indicates that no permission is granted at that position, can be omit‐
ted and only the required letters have to be specified.
The letters above are listed in the order they would be specified in
positional notation.
Permissions can be specified with these letters in the following way:
rwx--D--------
The hyphens can be removed to compact the string as follows:
rwxD
The optional inheritance flags can be specified in the three formats.
The first format uses words to indicate the various inheritance flags
separated with a forward slash (/) character.
file_inherit (f) Inherit to all newly created files.
dir_inherit (d) Inherit to all newly created directories.
inherit_only (i) When placed on a directory, do not apply to the
directory, only to newly created files and directo‐
ries. This flag requires that either file_inherit
and or dir_inherit is also specified.
no_propagate (n) Indicates that ACL entries should be inherited to
objects in a directory, but inheritance should stop
after descending one level. This flag is dependent
upon either file_inherit and or dir_inherit also
being specified.
The inheritance flags listed can also be specified in the compact for‐
mat or as positional arguments similar to the ls -V format. A hyphen
character indicates that the inheritance flag at that postion is not
specified in the positional ACL format.
The inheritance flags can be specified with these letters in any of the
following equivalent ways.
file_inherit/dir_inherit/no_propagate
fd-n--
fdn
With this inheritance model, an ACL entry can be specified such as:
user:tom:read_data/write_data/read_attributes:file_inherit:allow
user:fred:read_data:file_inherit/dir_inherit:deny
user:bob:read_data:allow
OPTIONS
The following options are supported:
-f Force. chmod does not complain if it fails to change the mode of
a file.
-R Recursively descends through directory arguments, setting the
mode for each file as described above. When symbolic links are
encountered, the mode of the target file is changed, but no
recursion takes place.
OPERANDS
The following operands are supported:
absolute-mode Represents the change to be made to the file mode
symbolic-mode-list bits of each file named by one of the file oper‐
ands. See Absolute Mode and Symbolic Mode above
in the section for more information.
acl_operation Represents the modification to be performed on
the file's ACL. See ACL Operation in the DESCRIP‐
TION section for more information.
acl_operation is one of the following:
A[number] -
A-acl_specification
A[index]{+|=}acl_specification
file A path name of a file whose file mode bits are to
be modified.
USAGE
See largefile(5) for the description of the behavior of chmod when
encountering files greater than or equal to 2 Gbyte ( 2^31 bytes).
EXAMPLES
Example 1 Denying execute Permission
The following example denies execute permission to everyone:
example% chmod a-x file
Example 2 Allowing read-only Permission
The following example allows only read permission to everyone:
example% chmod 444 file
Example 3 Making a File readable and writable
The following example makes a file readable and writable by the group
and others:
example% chmod go+rw file
example% chmod 066 file
Example 4 Locking a File From Access
The following example locks a file from access:
example% chmod +l file
Example 5 Granting read, write, execute, and set group-ID Permission on
a File
The following example grants everyone read, write, and execute permis‐
sions on the file, and turns on the set group-ID:
example% chmod a=rwx,g+s file
example% chmod 2777 file
Example 6 Prepending a New ACL Entry on a ZFS File
The following example prepends a new ACL entry on a ZFS file.
First, display the current ACL:
example% ls -v file.3
-rw-r--r-- 1 marks staff 0 Oct 9 15:49 file.3
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Issue the following command:
example% chmod A+user:lp:read_data:deny file.3
Display the new ACL:
example% ls -v file.3
-rw-r--r--+ 1 marks staff 0 Oct 9 15:49 file.3
0:user:lp:read_data:deny
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
6:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Example 7 Prepending a New POSIX-draft ACL Entry on a UFS File
The following example prepends a new POSIX-draft ACL entry on a UFS
file.
First, display the current ACL:
example% ls -v file.2
-rw-r--r-- 1 marks staff 0 Oct 9 15:52 file.2
0:user::rw-
1:group::r-- #effective:r--
2:mask:r--
3:other:r--
Issue the following command:
example% chmod A+user:lp:-wx file.2
Display the new ACL:
example% ls -v file.2
-rw-r--r--+ 1 marks staff 0 Oct 9 15:52 file.2
0:user::rw-
1:user:lp:-wx #effective:---
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
Example 8 Inserting an ACL Entry in a Specific Position on a ZFS file
The following example inserts an ACL entry in a specific position on a
ZFS file system. It also illustrates the compact ACL format.
First, display the ACL to pick a location to insert a new ACE.
example% ls -V file.1
-rw-r--r--+ 1 root root 0 Oct 6 12:16 file.1
user:lp:rw------------:------:allow
owner@:--x-----------:------:deny
owner@:rw-p---A-W-Co-:------:allow
group@:-wxp----------:------:deny
group@:r-------------:------:allow
everyone@:-wxp---A-W-Co-:------:deny
everyone@:r-----a-R-c--s:------:allow
Next, insert a new entry in location 3. This causes the entries
that are currently in position 3 - 6 to be pushed down.
Issue the following command:
example% chmod A3+user:marks:r:deny file.1
Display the new ACL:
example% ls -V file.1
-rw-r--r--+ 1 root staff 0 Feb 3 14:13 file.1
user:lp:rw------------:------:allow
owner@:--x-----------:------:deny
owner@:rw-p---A-W-Co-:------:allow
user:marks:r-------------:------:deny
group@:-wxp----------:------:deny
group@:r-------------:------:allow
everyone@:-wxp---A-W-Co-:------:deny
everyone@:r-----a-R-c--s:------:allow
Example 9 Inserting a POSIX-draft ACL in a Specific Position on a UFS
File
The file system reorders ACLs when they are stored in the file system.
The following example illustrates this behavior.
example% ls -v file.1
-rw-r--r--+ 1 root root 0 Sep 29 16:10 file.1
0:user::rw-
1:user:lp:rw- #effective:r--
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
Now, insert an entry at index position 3. The command works, but the
file system reorders the ACL.
example% chmod A3+user:marks:rw- file.1
example% ls -v file.1
-rw-r--r--+ 1 root root 0 Sep 29 16:10 file.1
0:user::rw-
1:user:lp:rw- #effective:r--
2:user:marks:rw- #effective:r--
3:group::r-- #effective:r--
4:mask:r--
5:other:r--
Rather than inserting the ACL entry in position 3 as requested, it
actually ends up in position 2.
Example 10 Removing an ACL Entry on a ZFS File
The following example removes the lp entry from an ACL:
example% ls -v file.3
-rw-r--r--+ 1 marks staff 0 Oct 9 15:49 file.3
0:user:lp:read_data:deny
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
6:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
example% chmod A-user:lp:read_data:deny file.3
example% ls -v file.3
-rw-r--r-- 1 marks staff 0 Oct 9 15:49 file.3
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Example 11 Removing a POSIX-draft ACL on a UFS File
The following example removes the lp entry from an ACL:
example% ls -v file.2
-rw-r--r--+ 1 marks staff 0 Oct 9 15:52 file.2
0:user::rw-
1:user:lp:-wx #effective:---
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
example% chmod A-user:lp:-wx file.2
example% ls -v file.2
-rw-r--r-- 1 marks staff 0 Oct 9 15:52 file.2
0:user::rw-
1:group::r-- #effective:r--
2:mask:r--
3:other:r--
Example 12 Removing a Specific ACL Entry by Index Number on a ZFS File
Consider the following ACL:
example% ls -v file
0:group:staff:read_data/write_data/execute/read_acl:allow
1:user:bin:read_data:deny
2:user:bin:read_data:allow
3:owner@:write_data/append_data:deny
4:owner@:read_data/write_xattr/execute/write_attributes/write_acl
/write_owner:allow
5:group@:write_data/append_data:deny
6:group@:read_data/execute:allow
7:everyone@:write_data/append_data/write_xattr/write_attributes
/write_acl/write_owner:deny
8:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
/synchronize:allow
Remove the second user entry for bin.
example% chmod A2- file
example% ls -v file
0:group:staff:read_data/write_data/execute/read_acl:allow
1:user:bin:read_data:deny
2:owner@:write_data/append_data:deny
3:owner@:read_data/write_xattr/execute/write_attributes/write_acl
/write_owner:allow
4:group@:write_data/append_data:deny
5:group@:read_data/execute:allow
6:everyone@:write_data/append_data/write_xattr/write_attributes
/write_acl/write_owner:deny
7:everyone@:read_data/read_xattr/execute/read_attributes/read_acl
/synchronize:allow
Example 13 Removing a Specific POSIX-draft ACL Entry on a UFS File
The following example removes the lp entry by index number from the
following ACL:
example% ls -v file.1
-rw-r--r--+ 1 root root 0 Sep 29 16:10 file.1
0:user::rw-
1:user:lp:rw- #effective:r--
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
example% chmod A1- file.1
example% ls -v
-rw-r--r--+ 1 root root 0 Sep 29 16:10 file.1
0:user::rw-
1:group::r-- #effective:r--
2:mask:r--
3:other:r--
Example 14 Removing All ACLs From a File
The following command works with either NFSv4/ZFS or POSIX-draft ACLs.
Consider the following ACL:
example% ls -v file.3
-rw-r--r--+ 1 marks staff 0 Oct 9 15:49 file.3
0:user:lp:read_data/write_data:allow
1:user:marks:read_acl:allow
2:owner@:execute:deny
3:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
4:group@:write_data/append_data/execute:deny
5:group@:read_data:allow
6:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
7:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
The existing ACL is effectively removed and is replaced with an ACL
that represents the permission bits of the file.
example% chmod A- file.3
example% ls -v file.3
-rw-r--r-- 1 marks staff 0 Oct 9 15:49 file.3
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Example 15 Replacing an Entire ACL Entry on a ZFS File
Use the following chmod syntax if you want to replace an ACL in its
entirety:
example% chmod A=owner@:read_data/write_data:allow,group@:read_data/
write_data:allow,user:lp:read_data:allow file.4
example% ls -v file.4
-rw-rw----+ 1 marks staff 0 Oct 9 16:12 file.4
0:owner@:read_data/write_data:allow
1:group@:read_data/write_data:allow
2:user:lp:read_data:allow
Example 16 Replacing an Entire POSIX-draft ACL on a UFS File
This operation is a little more complicated. The replacement ACL needs
the necessary entries to represent the file owner, file group owner,
other, mask and any additional entries you wish to set.
example% chmod A=user::rw-,group::rw-,other::---,mask:r--,
user:lp:r-- file.3
example% ls -v file.3
-rw-r-----+ 1 root root 0 Oct 9 16:14 file.3
0:user::rw-
1:user:lp:r-- #effective:r--
2:group::rw- #effective:r--
3:mask:r--
4:other:---
Example 17 Replacing a Specific Entry on a ZFS File
Consider the following ACL.
example% ls -v file.5
-rw-r--r--+ 1 marks staff 0 Oct 9 16:18 file.5
0:user:marks:read_data:allow
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
6:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
Now, change the allow access to a deny for user marks:
example% chmod A0=user:marks:read_data:deny file.5
example% ls -v file.5
-rw-r--r--+ 1 marks staff 0 Aug 23 09:11 file.5
0:user:marks:read_data:deny
1:owner@:read_data/write_data/append_data/write_xattr/write_attributes
/write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/write_attributes
/write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
:allow
Example 18 Replacing a Specific POSIX-draft ACL on a UFS File
Consider the following ACL.
example% ls -v file.4
-rw-r--r--+ 1 marks staff 0 Oct 9 16:21 file.4
0:user::rw-
1:user:lp:rwx #effective:r--
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
Now, change the permission on lp from rwx to r--:
example% chmod A1=user:lp:r-- file.4
example% ls -v file
-rw-r--r--+ 1 marks staff 0 Oct 9 16:21 file.4
0:user::rw-
1:user:lp:r-- #effective:r--
2:group::r-- #effective:r--
3:mask:r--
4:other:r--
Example 19 Setting ACL Inheritance Flags on a ZFS File
You can only set inheritance flags on ZFS files. When setting ACLs on
directories, several inheritance flags can be optionally set.
Suppose you have an ACL entry for user lp that you want to be inher‐
ited to newly created files in a directory. First, you need to create
an inheritable ACL entry on the directory:
example% chmod A+user:lp:read_data:file_inherit:allow test.dir
example% ls -dv test.dir
drwxr-xr-x+ 2 marks staff 2 Aug 23 09:08 test.dir/
0:user:lp:read_data:file_inherit:allow
1:owner@::deny
2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/write_xattr/execute/write_attributes/write_acl
/write_owner:allow
3:group@:add_file/write_data/add_subdirectory/append_data:deny
4:group@:list_directory/read_data/execute:allow
5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
/write_attributes/write_acl/write_owner:deny
6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
/read_acl/synchronize:allow
The lp entry is inherited to newly created files in the directory
test.dir.
example% touch test.dir/file.test
example% ls -v test.dir/file.test
-rw-r--r--+ 1 marks staff 0 Oct 9 16:29 test.dir/file.test
0:user:lp::deny
1:user:lp:read_data:allow
2:owner@:execute:deny
3:owner@:read_data/write_data/append_data/write_xattr/
write_attributes/write_acl/write_owner:allow
4:group@:write_data/append_data/execute:deny
5:group@:read_data:allow
6:everyone@:write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
7:everyone@:read_data/read_xattr/read_attributes/read_acl/
synchronize:allow
The user lp entry is inherited to the newly created file. Multiple com‐
binations of the inheritance flags can be specified. For example, if
you wanted the lp entry to also be inherited to directories, then the
following command can be used:
example% chmod A+user:lp:read_data:file_inherit/\
dir_inherit:allow test.dir
ENVIRONMENT VARIABLES
See environ(5) for descriptions of the following environment variables
that affect the execution of chmod: LANG, LC_ALL, LC_CTYPE, LC_MES‐
SAGES, and NLSPATH.
EXIT STATUS
The following exit values are returned:
0 Successful completion.
>0 An error occurred.
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Availability │SUNWcsu │
├─────────────────────────────┼─────────────────────────────┤
│CSI │Enabled │
├─────────────────────────────┼─────────────────────────────┤
│Interface Stability │Standard │
└─────────────────────────────┴─────────────────────────────┘
SEE ALSOgetfacl(1), ls(1), setfacl(1), chmod(2), acl(5), attributes(5), envi‐
ron(5), largefile(5), standards(5)NOTES
Absolute changes do not work for the set-group-ID bit of a directory.
You must use g+s or g-s.
chmod permits you to produce useless modes so long as they are not
illegal (for instance, making a text file executable). chmod does not
check the file type to see if mandatory locking is meaningful.
If the filesystem is mounted with the nosuid option, setuid execution
is not allowed.
If you use chmod to change the file group owner permissions on a file
with ACL entries, both the file group owner permissions and the ACL
mask are changed to the new permissions. Be aware that the new ACL mask
permissions can change the effective permissions for additional users
and groups who have ACL entries on the file. Use the getfacl(1) or
ls(1)command to make sure the appropriate permissions are set for all
ACL entries.
SunOS 5.10 14 Nov 2011 chmod(1)
