Using ACLs to Protect Sun QFS and SAM-QFS Files

Previous versions of Oracle Solaris supported an ACL implementation that was primarily based on the POSIX-draft ACL specification. The POSIX-draft based ACLs are used to protect UFS files and are translated by versions of NFS prior to NFSv4.

With the introduction of NFSv4, a new Oracle Solaris ACL model fully supports the interoperability that NFSv4 offers between UNIX and non-UNIX clients. The new ACL implementation, as defined in the NFSv4 specification, provides much richer semantics that are based on NT-style ACLs.

The main differences of the new ACL model are as follows:

Based on the NFSv4 specification and similar to NT-style ACLs.
Provide much more granular set of access privileges. For more information, see Table 8-3.
Set and displayed with the chmod and ls commands rather than the setfacl and getfacl commands.
Provide richer inheritance semantics for designating how access privileges are applied. For more information, see ACL Inheritance.

Both ACL models provide more fine-grained access control than is available with the standard file permissions. Much like POSIX-draft ACLs, the new ACLs are composed of multiple Access Control Entries (ACEs).

POSIX-draft style ACLs use a single entry to define what permissions are allowed and what permissions are denied. The new ACL model has two types of ACEs that affect access checking: ALLOW and DENY. As such, you cannot infer from any single ACE that defines a set of permissions whether the permissions not defined in that ACE are allowed or denied.

For more information about the new Oracle Solaris ACL model, see New Solaris ACL Model in Oracle Solaris Administration: ZFS File Systems.

Mapping User and Group Identities in SAM-QFS

Currently, SAM-QFS does not support ephemeral IDs or SIDs. Therefore, all Windows identities must be explicitly defined using the idmap service or must be provided by the active directory service. Identities encountered by the SMB server that do not have an explicit mapping defined will be defaulted automatically to the nobody identity.

For more information about identity mapping administration, see Chapter 2, Identity Mapping Administration (Tasks), in Oracle Solaris Administration: SMB and Windows Interoperability.

Creating and Converting File Systems to Support NFSv4 ACLs

POSIX ACLs are the default ACLs present in the SAM-QFS file systems. In order to support the SMB service, SAM-QFS file systems also have to support NFSv4 ACLs.

Use the sammkfs -A command to create a file system with NFSv4 ACLs. For example, to create a file system, sqfs1, with NFSv4 ACLs:
```
# sammkfs -A -S sqfs1
```
For more information about the -A option in the sammkfs command, see sammkfs(1M) in Sun QFS and Sun Storage Archive Manager 5.3 Reference Manual.
Use the samfsck -A command to convert existing POSIX ACLs to NFSv4 ACLs. For example, to convert from POSIX ACLS to NFSv4 ACLs on an existing file system, sqfs2:
```
# samfsck -F -A sqfs2 
```
Note - The conversion from POSIX ACLS to NFSv4 cannot be reversed. The conversion applies only to file systems versions V2 or V2A.

For more information about the -A option in the samfsck command, see samfsck(1M) in Sun QFS and Sun Storage Archive Manager 5.3 Reference Manual.

Syntax Descriptions for Setting ACLs

Two basic ACL formats are provided as follows:

Syntax for Setting Trivial ACLs

chmod [options] A[index]{+|=}owner@ |group@ |everyone@:access-permissions/...[:inheritance-flags]:deny | allow file

chmod [options] A-owner@, group@, everyone@:access-permissions/...[:inheritance-flags]:deny | allow file ...

chmod [options] A[index]- file

Syntax for Setting Non-Trivial ACLs

chmod [options] A[index]{+|=}user|group:name:access-permissions/...[:inheritance-flags]:deny | allow file

chmod [options] A-user|group:name:access-permissions/...[:inheritance-flags]:deny | allow file ...

chmod [options] A[index]- file

owner@, group@, everyone@: Identifies the ACL-entry-type for trivial ACL syntax. For a description of ACL-entry-types, see Table 8-2.
user or group:ACL-entry-ID=username or groupname: Identifies the ACL-entry-type for explicit ACL syntax. The user and group ACL-entry-type must also contain the ACL-entry-ID, username or groupname. For a description of ACL-entry-types, see Table 8-2.
access-permissions/.../: Identifies the access permissions that are granted or denied. For a description of ACL access privileges, see Table 8-3.
inheritance-flags: Identifies an optional list of ACL inheritance flags. For a description of the ACL inheritance flags, see Table 8-4.
deny | allow: Identifies whether the access permissions are granted or denied.

In the following example, the ACL-entry-ID value is not relevant.

group@:write_data/append_data/execute:deny

The following example includes an ACL-entry-ID because a specific user (ACL-entry-type) is included in the ACL.

0:user:gozer:list_directory/read_data/execute:allow

When an ACL entry is displayed, it looks similar to the following:

2:group@:write_data/append_data/execute:deny

The 2 or the index-ID designation in this example identifies the ACL entry in the larger ACL, which might have multiple entries for owner, specific UIDs, group, and everyone. You can specify the index-ID with the chmod command to identify which part of the ACL you want to modify. For example, you can identify index ID 3 as A3 to the chmod command, similar to the following:

chmod A3=user:venkman:read_acl:allow filename

ACL entry types, which are the ACL representations of owner, group, and other, are described in the following table.

Table 8-2 ACL Entry Type

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

ACL access privileges are described in the following table.

Table 8-3 ACL Access Privileges

Access Privilege	Description
`add_file`	Permission to add a new file to a directory.
`add_subdirectory`	On a directory, permission to create a subdirectory.
`delete`	Permission to delete a file.
`delete_child`	Permission to delete a file or directory within a directory.
`execute`	Permission to execute a file or search the contents of a directory.
`list_directory`	Permission to list the contents of a directory.
`read_acl`	Permission to read the ACL (`ls`).
`read_attributes`	Permission to read basic attributes (non-ACLs) of a file. (Think of basic attributes as the stat level attributes). Allowing this access mask bit means the entity can execute `ls`(1) and `stat`(2).
`read_data`	Permission to read the contents of the file.
`read_xattr`	Permission to read the extended attributes of a file or perform a lookup in the file's extended attributes directory.
`write_xattr`	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`	Permission to modify or replace the contents of a file.
`write_attributes`	Permission to change the times associated with a file or directory to an arbitrary value.
`write_acl`	Permission to write the ACL or the ability to modify the ACL by using the `chmod` command.
`write_owner`	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.

Example 8-3 Modifying Trivial ACLs on SAM-QFS Files

In the following example, a trivial ACL exists on file.1:

# ls -v file.1
-rw-r--r--   1 root     root      206674 Jun 14 10:54 file.1
     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

ACL Inheritance

The purpose of using ACL inheritance is so that a newly created file or directory can inherit the appropriate ACLs 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 optional inheritance flags are described in the following table.

Table 8-4 ACL Inheritance Flags

Inheritance Flag	Description
`file_inherit`	Only inherit the ACL from the parent directory to the directory's files.
`dir_inherit`	Only inherit the ACL from the parent directory to the directory's subdirectories.
`inherit_only`	Inherit the ACL from the parent director. This option applies only to newly created files or subdirectories and not to the directory itself. This flag requires the `file_inherit` flag, the `dir_inherit` flag, or both, to indicate what to inherit.
`no_propagate`	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.

By default, ACLs are not propagated through a directory structure.

Example 8-4 Granting Default ACL Inheritance

In the following example, a non-trivial ACE of read_data/write_data/execute is applied for user gozer on test.dir.

# chmod A+user:gozer:read_data/write_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 Jun 15 10:40 test.dir
     0:user:gozer:list_directory/read_data/add_file/write_data/execute:allow
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     2:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

If a test.dir subdirectory is created, the ACE for user gozer is not propagated. User gozer would only have access to sub.dir if the permissions on sub.dir granted him access as the file owner, group member, or everyone@.

# mkdir test.dir/sub.dir
# ls -dv test.dir/sub.dir
drwxr-xr-x   2 root     root           2 Jun 15 10:41 test.dir/sub.dir
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/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

Example 8-5 Granting ACL Inheritance on Files Within Directories

In the following example, certain permissions are applied to all the newly created files in a directory but the permissions do not apply to the directory itself. The file_inherit flag indicates that the permissions are for the files, and the inherit_only flag indicates that the permissions are for inheritance and will not apply to the directory itself.

# chmod A+user:bob:read_data/execute:file_inherit/inherit_only:deny mydir
# ls -vd mydir
dr-xr-xr-x+     2     root     root        4096 Jul 5 19:10 mydir 
   0:user:bob:list_directory/read_data/execute:file_inherit/inherit_only:deny
   1: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
   2:group@:list_directory/read_data/read_xattr/execute/read_attributes
      /read_acl/synchronize:allow
   3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
      /read_acl/synchronize:allow

If a myfile file is created in the mydir directory, the myfile file will inherit all the access permissions automatically.

# cd mydir
# touch myfile
# ls -v myfile
-r--r--r--+     1     root     root        0 Jul 5 19:11 myfile

   0:user:bob:read_data/execute:file_inherit/inherit_only:deny
   1:owner@:read_data/write_data/append_data/read_xattr/write_xattr
      /read_attributes/write_attributes/read_acl/write_acl/write_owner
      /synchronize:allow
   2:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
   3:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow

Skip Navigation Links
Exit Print View
	Sun QFS File System 5.3 Configuration and Administration Guide Sun QFS and Sun Storage Archive Manager 5.3 Information Library