svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
acl(7)
acl(7) Standards, Environments, Macros, Character Sets, and miscellany acl(7)
NAME
acl - Access Control Lists
DESCRIPTION
Access control lists (ACLs) are discretionary access control mechanisms
that grant and deny access to files and directories. Two different ACL
models are supported in the Solaris release: POSIX-draft ACLs and NFSv4
ACLs.
The older, POSIX-draft model is supported by the UFS file system. This
model is based on a withdrawn ACL POSIX specification that was never
standardized. It was subsequently withdrawn by the POSIX committee.
The other model is based on the standards of the NFSv4 working group
and is an approved standard from the Internet Engineering Task Force
(IETF). The ZFS file system uses the NFSv4 model, and provides richer
semantics and finer grained permission capabilities than the POSIX-
draft model.
POSIX-draft ACLs
POSIX-draft ACLs provide an alternative security mechanism to basic
UNIX file permissions in the Solaris release. Their purpose is to fur‐
ther restrict access to files and directories or to extend permissions
to a particular user. ACLs can be used to change the permissions for
the standard owner, group and other class bits of a file's mode. ACLs
can give additional users and groups access to the file. A directory
can also have a special kind of ACL called a default ACL, which defines
ACL entries to be inherited by descendents of the directory. POSIX-
draft ACLs have an ACL entry called mask. The mask defines the maximum
permissions that can be granted to additional user and group entries.
Whenever a file is created or its mode is changed by chmod(1) or
chmod(2), the mask is recomputed. It is recomputed to be the group per‐
mission defined in the mode passed to chmod(2).
The POSIX-draft ACL model uses the standard rwx model of traditional
UNIX permissions.
An ACL is represented as follows:
acl_entry[,acl_entry]...
Each acl_entry contains one ACL entry. An ACL entry is represented by
two or three colon-separated (:) fields.
user:[uid]:perms If uid is blank, it represents the file owner.
group:[gid]:perms If gid is blank, it represents the owning group.
other:perms Represents the file other class.
mask:perms Defines the MAX permission to hand out.
For example to give user joe read and write permissions, the ACL entry
is specified as:
user:joe:rw-
NFSv4 ACLs
The NFSv4 ACL model is based loosely on the Windows NT ACL model. The
ZFS file system uses the NFSv4 model, and provides richer semantics and
finer grained permission capabilities than the POSIX-draft model.
The major differences between NFSv4 and POSIX-draft ACLs are as fol‐
lows:
o NFSv4 ACLs provide finer grained permissions than the rwx
model.
o NFSv4 ACLs allow for both ALLOW and DENY entries.
o NFSv4 ACLs provide a rich set of inheritance semantics.
POSIX ACLs also have inheritance, but with the NFSv4 model
you can control the following inheritance features:
o Whether inheritance cascades to both files and directo‐
ries or only to files or directories.
o In the case of directories, you can indicate whether in‐
heritance is applied to the directory itself, to just
one level of subdirectories, or cascades to all subdi‐
rectories of the directory.
o NFSv4 ACLs provide a mechanism for hooking into a system's
audit trail, and for generating alarms. Currently, Solaris
does not support alarm generation.
o NFSv4 ACLs enable administrators to specify the order in
which ACL entries are checked. With POSIX-draft ACLs the
file system reorders ACL entries into a well defined, strict
access, checking order.
POSIX-draft ACL semantics can be achieved with NFSv4 ACLs. However,
only some NFSv4 ACLs can be translated to equivalent POSIX-draft ACLs.
Permissions can be specified in three different chmod ACL formats: ver‐
bose, 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 the 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. This includes the
ability to grow the file or write to any arbi‐
trary offset.
add_file (w) Permission to add a new file to a directory.
append_data (p) The ability to modify the 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) The ability to read the extended attributes of
a file or do a lookup in the extended attrib‐
utes directory.
write_xattr (W) The ability to create extended attributes or
write to the extended attributes directory.
execute (x) Permission to execute a file.
read_attributes (a) The ability to read basic attributes (non-ACLs)
of a file. Basic attributes are considered to
be the stat level attributes. Allowing this ac‐
cess mask bit means that the entity can execute
ls(1) and stat(2).
write_attributes (A) Permission to change the times associated with
a file or directory to an arbitrary value.
delete (d) Permission to delete the file.
delete_child (D) Permission to delete a file within a directory.
read_acl (c) Permission to read the ACL.
write_acl (C) Permission to write the ACL or the ability to
execute chmod(1).
write_owner (o) Permission to change the owner or the ability
to execute chown(1) or chgrp(1).
synchronize (s) Permission to access a file locally at the
server with synchronous reads and writes. Cur‐
rently, this permission is not supported.
The following inheritance flags are supported by NFSv4:
file_inherit (f) Inherit to all newly created files in a direc‐
tory.
dir_inherit (d) Inherit to all newly created directories in a
directory.
inherit_only (i) Placed on a directory, but does not apply to
the directory itself, only to newly created
created files and directories. This flag re‐
quires file_inherit and/or dir_inherit to in‐
dicate what to inherit.
no_propagate (n) Placed on directories and indicates that ACL
entries should only be inherited one level of
the tree. This flag requires file_inherit
and/or dir_inherit to indicate what to in‐
herit.
successful_access (S) Indicates if an alarm or audit record should
be initiated upon successful accesses. Used
with audit/alarm ACE types.
failed_access (F) Indicates if an alarm or audit record should
be initiated when access fails. Used with au‐
dit/alarm ACE types.
inherited (I) ACE was inherited.
- No permission granted.
An NFSv4 ACL is expressed using the following syntax:
acl_entry[,acl_entry]...
owner@:<perms>[:inheritance flags]:<allow|deny>
group@:<perms>[:inheritance flags]:<allow|deny>
everyone@:<perms>[:inheritance flags]:<allow|deny>
user:<username>[:inheritance flags]:<allow|deny>
group:<groupname>[:inheritance flags]:<allow|deny>
owner@:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
group@:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
everyone@:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
user:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
group:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
owner@ File owner
group@ Group owner
user Permissions for a specific user
group Permissions for a specific group
Permission and inheritance flags are separated by a / character.
ACL specification examples:
user:fred:read_data/write_data/read_attributes:file_inherit:allow
owner@:read_data:allow,group@:read_data:allow,user:tom:read_data:deny
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 in‐
dicates that no permission is granted at that position, can be omitted
and only the required letters have to be specified.
The letters above are listed in the order they would be specified in
positional notation.
With these letters you can specify permissions in the following equiva‐
lent ways.
user:fred:rw------R------:file_inherit:allow
Or you can remove the - and scrunch it together.
user:fred:rwR:file_inherit:allow
The inheritance flags can also be specified in a more compact manner,
as follows:
user:fred:rwR:f:allow
user:fred:rwR:f------:allow
Audit ACE Types
Where audit ACE types are supported, processes are required to have the
PRIV_FILE_AUDIT privilege in order to view and set audit ACL entries.
When retrieving an ACL, audit entries are skipped and not returned to a
caller who lacks appropriate privilege.
When an unprivileged process successfully sets a file ACL, existing au‐
dit ACL entries for the file are preserved, although they are not visi‐
ble to that process. Attempting to set an ACL which contains audit en‐
tries will result in an error if the caller lacks appropriate privi‐
lege.
ACL size limits
Unprivileged processes have a limit of setting a total of MAX_ACL_EN‐
TRIES combined allow/deny entries in an ACL. Privileged processes may
also set up to MAX_ACL_ENTRIES audit entries. Thus a privileged caller
will observe a limit of 2 * MAX_ACL_ENTRIES total entries, while un‐
privileged users will observe a limit of just MAX_ACL_ENTRIES total en‐
tries.
Shell-level Solaris API
The Solaris command interface supports the manipulation of ACLs. The
following Solaris utilities accommodate both ACL models:
chmod The chmod utility has been enhanced to allow for the set‐
ting and deleting of ACLs. This is achieved by extending
the symbolic-mode argument to support ACL manipulation. See
chmod(1) for details.
compress When a file is compressed any ACL associated with the orig‐
inal file is preserved with the compressed file.
cp By default, cp ignores ACLs, unless the -p option is speci‐
fied. When -p is specified the owner and group id, permis‐
sion modes, modification and access times, ACLs, and ex‐
tended attributes if applicable are preserved.
cpio ACLs are preserved when the -P option is specified.
find Find locates files with ACLs when the -acl flag is speci‐
fied.
ls By default ls does not display ACL information. When the -v
option is specified, a file's ACL is displayed.
mv When a file is moved, all attributes are carried along with
the renamed file. When a file is moved across a file system
boundary, the ACLs are replicated. If the ACL information
cannot be replicated, the move fails and the source file is
not removed.
rcp rcp has been enhanced to support copying. A file's ACL is
only preserved when the remote host supports ACLs.
tar ACLs are preserved when the -p option is specified.
Application-level API
The primary interfaces required to access file system ACLs at the pro‐
grammatic level are the acl_get() and acl_set() functions. These func‐
tions support both POSIX draft ACLs and NFSv4 ACLs.
To determine which types of ACL, if any, are supported with a given
file, use the pathconf(2) and fpathconf(2) functions with a value of
_PC_ACL_ENABLED for their name argument.
Retrieving a file's ACL
int acl_get(const char *path, int flag, acl_t **aclp);
int facl_get(int fd, int flag, acl_t **aclp);
The acl_get(3SEC) and facl_get(3SEC) functions retrieves an ACL on a
file whose name is given by path or referenced by the open file de‐
scriptor fd. The flag argument specifies whether a trivial ACL should
be retrieved. When the flag argument equals ACL_NO_TRIVIAL then only
ACLs that are not trivial are retrieved. The ACL is returned in the
aclp argument.
Freeing ACL structure
void acl_free(acl_t *aclp);
The acl_free() function frees up memory allocated for the argument
aclp;.
Setting an ACL on a file
int acl_set(const char *path, acl_t *aclp);
int facl_set(int fd, acl_t *aclp);
The acl_set(3SEC) and facl_get(3SEC) functions are used for setting an
ACL on a file whose name is given by path or referenced by the open
file descriptor fd. The aclp argument specifies the ACL to set. The
acl_set(3SEC) translates an POSIX-draft ACL into a NFSv4 ACL when the
target file systems supports NFSv4 ACLs. No translation is performed
when trying to set an NFSv4 ACL on a POSIX-draft ACL supported file
system.
Determining an ACL's trivialness
int acl_trivial(const char *path);
The acl_trivial() function is used to determine whether a file has a
trivial ACL. Whether an ACL is trivial depends on the type of the ACL.
A POSIX draft ACL is nontrivial if it has greater than MIN_ACL_ENTRIES.
An NFSv4/ZFS-style ACL is nontrivial if it either has entries other
than owner@, group@, and everyone@, has inheritance flags set, or is
not ordered in a manner that meets POSIX access control requirements.
Removing all ACLs from a file
int acl_strip(const char *path, uid_t uid, gid_t gid, mode_t mode);
The acl_strip() function removes all ACLs from a file and replaces them
with a trivial ACL based off of the passed in argument mode. After re‐
placing the ACL the owner and group of the file are set to the values
specified in the uid and gid parameters.
Converting ACLs to/from external representation
int acl_fromtext(const char *path, acl_t **aclp);
char *acl_totext(acl_t *aclp, int flags);
The acl_text() function converts an internal ACL representation pointed
to by aclp into an external representation. See DESCRIPTION for details
about external representation.
The acl_fromtext() functions converts and external representation into
an internal representation. See DESCRIPTION for details about external
representation.
EXAMPLES
The following examples demonstrate how the API can be used to perform
basic operations on ACLs.
Example 1 Retrieving and Setting an ACL
Use the following to retrieve an ACL and set it on another file:
error = acl_get("file", ACL_NO_TRIVIAL, &aclp);
if (error == 0 && aclp != NULL) {
error = acl_set("file2", aclp);
acl_free(aclp);
}
...
Example 2 Retrieving and Setting Any ACLs
Use the following to retrieve any ACL, including trivial ACLs, and set
it on another file:
error = acl_get("file3", 0, &aclp);
if (error == 0) {
error = acl_set("file4", aclp)
acl_free(aclp);
}
...
Example 3 Determining if a File has a Trivial ACL
Use the following to determine if a file has a trivial ACL:
istrivial = acl_trivial("file")
if (istrivial == 0)
printf("file %s has a trivial ACL\n", file);
else
printf("file %s has a NON-trivial ACL\n", file);
...
Example 4 Removing all ACLs from a File
Use the following to remove all ACLs from a file, and set a new mode,
owner, and group:
error = acl_strip("file", 10, 100, 0644);
...
SEE ALSO
chgrp(1), chmod(1), chown(1), cp(1), cpio(1), find(1), ls(1), mv(1),
tar(1), acl(2), chmod(2), fpathconf(2), pathconf(2), stat(2),
acl_free(3SEC), acl_fromtext(3SEC), acl_get(3SEC), acl_strip(3SEC),
acl_trivial(3SEC), aclcheck(3SEC), aclsort(3SEC)
Securing Files and Verifying File Integrity in Oracle Solaris 11.4
HISTORY
Support for NFSv4 ACLs was added to Solaris in Solaris 10 3/05.
Support for POSIX-draft ACLs was added to Solaris in Solaris 2.5.
Oracle Solaris 11.4 12 Sep 2023 acl(7)