Go to main content

Securing Files and Verifying File Integrity in Oracle® Solaris 11.4

Exit Print View

Updated: August 2018
 
 

Oracle Solaris ACL Model

The Oracle Solaris ACL model fully supports the interoperability that NFSv4 offers between UNIX and non-UNIX clients. ZFS ACLs are similar to Windows NT-style ACLs, and provide more fine-grained access control than standard file permissions provide. ACLs are set and displayed with the chmod and ls commands.

The ACL model has two types of Access Control Entries (ACEs) that affect access checking: ALLOW and DENY. Therefore, you cannot infer from any single ACE that defines a set of permissions whether the permissions that are not defined in that ACE are allowed or denied.

For information about ACLs and backup products, see Saving ZFS Data With Other Backup Products in Managing ZFS File Systems in Oracle Solaris 11.4.

ACL Formats

    ACLs have two basic formats:

  • Trivial ACL – Contains only entries for traditional UNIX user categories that are represented as owner@, group@, and everyone@.

    For a newly created file, the default ACL has the following entries:

    0:owner@:read_data/write_data/append_data/read_xattr/write_xattr
    /read_attributes/write_attributes/read_acl/write_acl/write_owner
    /synchronize:allow
    1:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
    2:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
    :allow

    For a newly created directory, the default ACL has the following entries:

    0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
    /append_data/read_xattr/write_xattr/execute/delete_child
    /read_attributes/write_attributes/read_acl/write_acl/write_owner
    /synchronize:allow
    1:group@:list_directory/read_data/read_xattr/execute/read_attributes
    /read_acl/synchronize:allow
    2:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
    /read_acl/synchronize:allow
  • Non-Trivial ACL – Contains entries for added user categories. The entries might also include inheritance flags, or are ordered in a non-traditional way.

    A non-trivial entry might look like the following example, where permissions are specifically granted to user Jan.

    0:user:jan:read_data/write_data:file_inherit:allow

ACL Entry Descriptions

Use the following sample entry as a reference to understand the elements that comprise an ACL entry. These elements apply to both trivial and non-trivial ACLs.

0:user:jan:read_data/write_data:file_inherit:allow
Index

A number at the beginning of the entry, such as the number zero (0) in the example. The index identifies a specific entry and distinguishes the entry from others in the ACL.

ACL entry type

The user category. In trivial ACLs, only entries for owner@, group@, and everyone@ are set. In non-trivial ACLs, user:username and group:groupname are added. In the example, the entry type is user:jan.

Access privileges

Permissions that are granted or denied to the entry type. In the example, user Jan's permissions are read_data and write_data.

Inheritance flags

An optional list of ACL flags that control how permissions are propagated in a directory structure, including flags that audit access to files and directories. In the sample entry, file_inherit is also granted to user Jan.

Audit flag

An optional flag that enables you to audit access and changes that are being made to a file.

Permission control

Determines whether the permissions in an entry are allowed or denied. In the example, the permissions for Jan are allowed.

The following table describes each ACL entry type.

Table 7  ACL Entry Types
ACL Entry Type
Format
Description
owner@
Trivial
Specifies the access granted to the owner of the object.
group@
Trivial
Specifies the access granted to the owning group of the object.
everyone@
Trivial
Specifies the access granted to any user or group that does not match any other ACL entry.
user
Non-trivial
With a user name, specifies the access granted to an additional user of the object. Must include the ACL-entry-ID, which contains a user name or user ID. If the value is not a valid numeric UID or user name, the ACL entry type is invalid.
group
Non-trivial
With a group name, specifies the access granted to an additional group of the object. Must include the ACL entry ID, which contains a group name or group ID. If the value is not a valid numeric GID or group name, the ACL entry type is invalid.

The following table describes ACL access privileges.

Table 8  ACL Access Privileges
Access Privilege
Compact Access Privilege
Description
add_file
w
Permission to add a new file to a directory.
add_subdirectory
p
On a directory, permission to create a subdirectory.
append_data
p
On a file, permission to modify from the end of the file (EOF).
delete
d
Permission to delete a file. For more information about specific delete permission behavior, see Figure 9, Table 9, ACL delete and delete_child Permission Behavior.
delete_child
D
Permission to delete a file or directory within a directory. For more information about specific delete_child permission behavior, see Figure 9, Table 9, ACL delete and delete_child Permission Behavior.
execute
x
Permission to execute a file or search the contents of a directory.
list_directory
r
Permission to list the contents of a directory.
read_acl
c
Permission to read the ACL (ls).
read_attributes
a
Permission to read basic attributes (non-ACLs) of a file, which are equivalent to stat level attributes. Allowing this access mask bit means the entity can execute ls(1) and stat(2).
read_data
r
Permission to read the contents of the file.
read_xattr
R
Permission to read the extended attributes of a file or perform a lookup in the file's extended attributes directory.
synchronize
s
Permission to access a file locally at the ZFS server with synchronized read and write operations.
write_xattr
W
Permission to create extended attributes or write to the extended attributes directory.
Granting this permission to a user means that the user can create an extended attribute directory for a file. The attribute file's permissions control the user's access to the attribute.
write_data
w
Permission to modify or replace the contents of a file.
write_attributes
A
Permission to change the times associated with a file or directory to an arbitrary value.
write_acl
C
Permission to write the ACL or the ability to modify the ACL by using the chmod command.
write_owner
o
Permission to change the file's owner or group. Or, the ability to execute the chown or chgrp commands on the file.
Permission to take ownership of a file or permission to change the group ownership of the file to a group of which the user is a member. If you want to change the file or group ownership to an arbitrary user or group, then the PRIV_FILE_CHOWN privilege is required.

The following table provides additional details about ACL delete and delete_child behavior.

Table 9  ACL delete and delete_child Permission Behavior
Parent Directory Permissions
Target Object Permissions
" " (empty)
ACL allows delete
ACL denies delete
Delete permission unspecified
ACL allows delete_child
Permit
Permit
Permit
ACL denies delete_child
Permit
Deny
Deny
ACL allows only write and execute
Permit
Permit
Permit
ACL denies write and execute
Permit
Deny
Deny

ZFS ACL Sets

    An ACL set consists of a combination of ACL permissions. These ACL sets of permissions are predefined and cannot be modified.

  • full_set – All permissions

  • modify_set – All permissions except write_acl and write_owner

  • read_setread_data, read_attributes, read_xattr, and read_acl

  • write_setwrite_data, append_data, write_attributes, and write_xattr

You can apply an ACL set rather than having to set individual permissions separately.

Example 7  Using an ACL Set to Assign a Combination of ACL Permissions

With the read_set ACL set, the user jan can read ACLs as well as file contents and their basic and extended attributes.

$ chmod A+user:jan:read_set:allow file.1
$ ls -v file.1
-r--r--r--+  1 root     root      206695 Jul 20 13:43 file.1
0:user:jan:read_data/read_xattr/read_attributes/read_acl:allow
...

ACL Inheritance

ACL inheritance means that a newly created file or directory can inherit the ACLs that they are intended to inherit without disregarding the existing permission bits on the parent directory.

By default, ACLs are not propagated. If you set a non-trivial ACL on a directory, it is not inherited to any subsequent directory. You must specify the inheritance of an ACL on a file or directory.

The following table describes the optional inheritance flags.

Table 10  ACL Inheritance Flags
Inheritance Flag
Compact Inheritance Flag
Description
file_inherit
f
Only inherit the ACL from the parent directory to the directory's files.
dir_inherit
d
Only inherit the ACL from the parent directory to the directory's subdirectories.
inherit_only
i
Inherit the ACL from the parent directory. Applies only to newly created files or subdirectories and not the directory itself. This flag requires the file_inherit flag, the dir_inherit flag, or both, to indicate what to inherit.
no_propagate
n
Only inherit the ACL from the parent directory to the first-level contents of the directory, not the second-level or subsequent contents. This flag requires the file_inherit flag, the dir_inherit flag, or both, to indicate what to inherit.
-
N/A
No permission granted.
successful_access
S
Indicates whether an alarm or audit record should be initiated upon a successful access. This flag is used with audit or alarm ACE types.
failed_access
F
Indicates whether an alarm or audit record should be initiated when an access fails. This flag is used with audit or alarm ACE types.
inherited
I
Indicates that an ACE was inherited.

In addition, you can set a default ACL inheritance policy on the file system that is more strict or less strict by using the aclinherit file system property. For more information about this property, see ACL Properties.

For more information about setting ACL inheritance on ZFS files, see Setting ACL Inheritance on ZFS Files.

ACL Properties

    The ZFS file system includes the ACL properties to determine the specific behavior of ACL inheritance and ACL interaction with chmod operations. These properties are:

  • aclinherit – Determine the behavior of ACL inheritance. Values include the following:

    • restricted – For new objects, the write_owner and write_acl permissions are removed when an ACL entry is inherited. This is the default mode.

    • discard – For new objects, no ACL entries are inherited when a file or directory is created. The ACL on the file or directory is equal to the permission mode of the file or directory.

    • noallow – For new objects, only inheritable ACL entries that have an access type of deny are inherited.

    • passthrough – When a property value is set to passthrough, files are created with a mode determined by the inheritable ACEs. If no inheritable ACEs exist that affect the mode, then the mode is set in accordance to the requested mode from the application.

    • passthrough-x – Has the same semantics as passthrough except that files are created with the execute (x) permission only if the execute permission is set in file creation mode and in an inheritable ACE that affects the mode.

    For more information about the aclinherit modes, see Modifying ACL Inheritance With the ACL Inherit Mode.

  • aclmode – Modifies ACL behavior when a file is initially created or controls how an ACL is modified during a chmod operation. Values include the following:

    • discard – Deletes all ACL entries that do not represent the mode of the file. This is the default mode.

    • mask – Reduces user or group permissions. The permissions are reduced such that they are no greater than the group permission bits unless it is a user entry that has the same UID as the owner of the file or directory. In this case, the ACL permissions are reduced so that they are no greater than owner permission bits. The mask value also preserves the ACL across mode changes, provided that an explicit ACL set operation has not been performed.

    • passthrough – Indicates that no changes are made to the ACL other than generating the necessary ACL entries to represent the new mode of the file or directory.

    For more information about using the aclmode property, see Example 9, ACL Properties and Modified ACL Permissions.