Go to main content

Securing Files and Verifying File Integrity in Oracle® Solaris 11.3

Exit Print View

Updated: October 2017
 
 

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 a description of the model, see the NFSv4 ACLs section of the acl(5) man page. For information about backup products, see Saving ZFS Data With Other Backup Products in Managing ZFS File Systems in Oracle Solaris 11.3.

Rights to Modify ZFS ACLs

    You can assign and modify ACLs of the files and directories that you own. For files that others own, you must get permission in one of the following ways to assign and modify those ACLs:

  • The owner of the file or directory gave you the write_acl permission:

    $ chmod A+user:jdoe:write_acl:f:allow file.1
  • You are assigned the Object Access Management rights profile. If you are not assigned a profile shell as your default shell, run the pfbash or pfexec command before running the command that changes the ACL.

  • You are assigned the root role.

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 grants owner@ all permissions, and prevents group@ and everyone@ from modifying the file and its attributes:

    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@:/** same as group@ **/

    For a newly created directory, the default ACL grants owner@ all permissions, and prevents group@ and everyone@ from modifying the directory and its attributes:

    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@:/** same as group@ **/
  • 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 is similar to the following example, which grants user jan specific permissions.

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

For a description of ACL access privileges, see the NFSv4 ACLs section of the acl(5) man page.

ACL Entry Descriptions

The following entry illustrates 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. Non-trivial ACL entry types are user:username and group:groupname. In the example, the entry type is user:jan.

Access privileges

Permissions that are granted or denied to the entry type. In the example, the user is granted read_data and write_data.

Inheritance flags

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

Permission control

Determines whether the permissions in an entry are allowed or denied. In the example, the permissions 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 can be a user name or a user ID.
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 can be a group name or a group ID.

ZFS ACL Sets

    ZFS ACL sets are predefined combinations of ACL permissions. You cannot extend the sets.

  • 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 separately setting individual permissions.

Example 7  Applying an ACL Set to a File

With the addition of the read_set ACL set, the user jan can read file contents and the file's basic and extended attributes, and retain the default permissions.

$ pfexec 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 Properties

    The ZFS file system includes two properties that affect ACLs:

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

    By default, ACL entries are discarded. Other possible modes are a mask that reduces user or group permissions, and a passthrough that leaves the ACLs in effect.

    For more information about aclmode values, see the aclmode entry in the zfs(1M) man page and Example 14, Showing the Effects of the aclmode and aclinherit Properties on ACL Permissions.

  • aclinherit – Determines the behavior of ACL inheritance and ACL interaction with chmod operations.

    By default, write_owner and write_acl permissions are removed when an ACL entry is inherited. Other possible behaviors are to discard all ACL entries, only inherit deny entries, and leave the ACLs in effect with passthrough.

    For more information about aclinherit values, see Effect of ACL Inherit Mode on ACL Inheritance and the aclinherit entry in the zfs(1M) man page.

ACL Inheritance Flags

ACL inheritance enables a newly created file or directory to inherit the ACLs that it should inherit without disregarding the existing permission bits on the parent directory. By default, ACLs are not inherited. A non-trivial ACL on a directory is not inherited to any subsequent directory. You must specify the inheritance of an ACL on a file or directory.

    ZFS and NFSv4 provide the following inheritance flags. The letters in parentheses are the compact format of the flag:

  • file_inherit (f) – Inherit from parent directory.

  • dir_inherit (d) – Inherit from parent directory.

  • inherit_only (i) – Newly created files or subdirectories inherit from the parent directory.

  • no_propagate (n) – Inherit only to the first level directory.

  • failed_access (F) – Alarm or audit record created at failed access.

  • successful_access (S) – Alarm or audit record created at successful access.

  • - – No permissions.

  • inherited (I) – Indicator of inheritance.

For a full description of the optional inheritance flags, see the NFSv4 ACLs section of the acl(5) man page.

In addition, you can change the default ACL inheritance policy on a file system by using the aclinherit file system property. For more information about this property, see ACL Properties and Setting ACL Inheritance on ZFS Files.


Note - Currently, the successful_access, failed_access, and inherited flags apply only to the SMB server.