
sun.com \| docs.sun.com	How To Buy \| My Sun \| Worldwide Sites

Previous Contents Next

Chapter 7

Using ACLs to Protect ZFS Files

This chapter provides information about using access control lists (ACLs) to protect your ZFS files by providing more granular permissions then the standard UNIX permissions.

The following sections are provided in this chapter.

7.1 New Solaris ACL Model

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

With the introduction of NFSv4, a new ACL model is needed to fully support the interoperability that NFSv4 hopes to achieve between UNIX and non-UNIX clients. The new ACL implementation, as defined in the NFSv4 specification, provide 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 are similar to NT-style ACLs.
Much more granular set of access privileges. For more information, see Table 7-2.
Set and displayed with the chmod and ls commands rather than the setfacl and getfacl commands.
Richer inheritance semantics for designating how access privileges are applied from directory to subdirectories, and so on. For more information, see 7.1.2 ACL Inheritance.

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

POSIX-draft style ACLs use a single entry to define what is allowed and also what is denied for the user or group that the entry applies to. The new ACL model has two types of ACEs that play a role in access checking: ALLOW and DENY. This means that you can't infer from any single ACE that defines some set of permissions whether or not the permissions that weren't defined in that ACE are allowed or denied.

Translation between NFSv4-style ACLs and POSIX-draft ACLs is as follows:

If you use any ACL-aware utility, such as the cp, mv, tar, cpio, or rcp commands, to transfer UFS files with ACLs to a ZFS file system, the POSIX-draft ACLs are translated into the equivalent NFSv4-style ACLs.
NFSv4-style ACLs are not translated to POSIX-draft ACLs. You will see a message similar to the following:
# cp -p filea /var/tmp cp: failed to set acl entries on /var/tmp/filea
If you attempt to set a NFSv4-style ACL on a UFS file, you will see a message similar to the following:
chmod: ERROR: ACL type's are different

If you attempt to set a POSIX-style ACL on a ZFS file, you will see messages similar to the following:

# getfacl filea
File system doesn't support aclent_t style ACL's.
See acl(5) for more information on Solaris ACL support.

7.1.1 ACL Format Description

The basic ACL format is as follows:

Syntax A:

ACL-entry-type=owner@, group@, everyone@:access-permissions/.../:deny | allow[:inheritance-flags]

Syntax B:

ACL-entry-type=user or group:ACL-entry-ID=username or groupname:access-permissions/.../:deny | allow[:inheritance-flags]

ACL-entry-type=owner@, group@, everyone@	Identifies owner@, group@, or everyone@ as displayed in Syntax A. For a description of ACL-entry-types, see Table 7-1.
ACL-entry-type=user or group:ACL-entry-ID=username or groupname	Identifies user or group as displayed in Syntax B. The user and group ACL-entry-type must also contains the ACL-entry-ID: username or groupname. For a description of ACL-entry-types, see Table 7-1.
access-permissions/.../	Identifies the access permissions that are granted or denied. For a description of ACL access permissions, see Table 7-2.
deny \| allow	Identifies whether the access permissions are granted or denied.
inheritance-flags	Optional list of ACL inheritance flags. For a description of the ACL inheritance flags, see Table 7-3.

For example:

group@:write_data/append_data/execute:deny

In the above example, the ACL-entry-ID value is not relevant. 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 the above example, identifies the ACL entry in the larger ACL, which might have multiple entries for owner, specific UIDs, group, and everyone. You can identify 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 A#3 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 7-1 ACL Entry Types

ACL Entry Types	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 userID. If the username can't be resolved to a UID, then the entry is assumed to be a numeric UID.
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 groupID. If the groupname can't be resolved to a GID, then the entry is assumed to be a numeric GID.

Access privileges are described in the following table.

Table 7-2 ACL Access Privileges

Access Privilege	Description
add_file	Permission to add a new file to a directory.
add_subdirectory	Permission to create a subdirectory in a directory.
append_data	On a directory, permission to create a subdirectory. On a file, permission to modify the contents of a file.
delete	Permission to delete the file.
delete_child	Permission to delete a file or directory within a directory.
execute	Permission to execute a file.
list_directory	Permission to list the contents of a directory.
read_acl	Permission to read the ACL (ls).
read_attributes	The ability to read basic attributes (non-ACLs) of a file. Basic attributes can be thought of as the stat level attributes. Allowing this access mask bit would mean the entity can execute ls(1) and stat(2).
read_data	Permission to read the contents of the file.
read_xattrs	The ability to read the extended attributes of a file or do a lookup in the file's extended attributes directory.
synchronize	Placeholder, unimplemented at this time.
write_xattrs	The ability to create extended attributes or write to the extended attributes directory. Granting this permission to a user means that the user will be able to create an extended attribute directory for the 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 with chmod(1).
write_owner	Permission to change the file's owner or group. Or, the ability to execute chown(1) or chgrp(1) on the file. Permission to take ownership of a file or the ability to change the group ownership of the file to a group of which the user is a member. If you wish to change the file or group ownership to an arbitrary user or group, then the PRIV_FILE_CHOWN privilege is required.

Previous Contents Next