Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Next 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 Previous     Contents     Next Next