---
name: "acl"
section: "9freebsd"
platform: "linux"
package: "freebsd-manpages"
version: "12.2-2"
release: "Debian 13 (Trixie)"
platforms: ["linux"]
url: "https://new.carta.tech/acl/9freebsd"
---

# acl(9freebsd)

virtual file system access control lists

## NAME

**acl** – virtual file system access control lists

## SYNOPSIS

**#include \<sys/param.h\>**

**#include \<sys/vnode.h\>**

**#include \<sys/acl.h\>**

In the kernel configuration file: **options UFS\_ACL**

## DESCRIPTION

Access control lists, or ACLs, allow fine-grained specification of rights for vnodes representing files and directories. However, as there are a plethora of file systems with differing ACL semantics, the vnode interface is aware only of the syntax of ACLs, relying on the underlying file system to implement the details. Depending on the underlying file system, each file or directory may have zero or more ACLs associated with it, named using the *type* field of the appropriate vnode ACL calls: [VOP\_ACLCHECK(9)](/VOP_ACLCHECK/9.md), [VOP\_GETACL(9)](/VOP_GETACL/9.md), and [VOP\_SETACL(9)](/VOP_SETACL/9.md).

Currently, each ACL is represented in-kernel by a fixed-size *acl* structure, defined as follows:

```
struct acl {
        unsigned int            acl_maxcnt;
        unsigned int            acl_cnt;
        int                     acl_spare[4];
        struct acl_entry        acl_entry[ACL_MAX_ENTRIES];
};
```

An ACL is constructed from a fixed size array of ACL entries, each of which consists of a set of permissions, principal namespace, and principal identifier. In this implementation, the *acl\_maxcnt* field is always set to ACL\_MAX\_ENTRIES.

Each individual ACL entry is of the type *acl\_entry\_t*, which is a structure with the following members:

- *acl\_tag\_t* *ae\_tag*

  The following is a list of definitions of ACL types to be set in *ae\_tag*:

  - ACL\_UNDEFINED\_FIELD

    Undefined ACL type.

  - ACL\_USER\_OBJ

    Discretionary access rights for processes whose effective user ID matches the user ID of the file's owner.

  - ACL\_USER

    Discretionary access rights for processes whose effective user ID matches the ACL entry qualifier.

  - ACL\_GROUP\_OBJ

    Discretionary access rights for processes whose effective group ID or any supplemental groups match the group ID of the file's owner.

  - ACL\_GROUP

    Discretionary access rights for processes whose effective group ID or any supplemental groups match the ACL entry qualifier.

  - ACL\_MASK

    The maximum discretionary access rights that can be granted to a process in the file group class. This is only valid for POSIX.1e ACLs.

  - ACL\_OTHER

    Discretionary access rights for processes not covered by any other ACL entry. This is only valid for POSIX.1e ACLs.

  - ACL\_OTHER\_OBJ

    Same as ACL\_OTHER.

  - ACL\_EVERYONE

    Discretionary access rights for all users. This is only valid for NFSv4 ACLs.

    Each POSIX.1e ACL must contain exactly one ACL\_USER\_OBJ, one ACL\_GROUP\_OBJ, and one ACL\_OTHER. If any of ACL\_USER, ACL\_GROUP, or ACL\_OTHER are present, then exactly one ACL\_MASK entry should be present.

- *uid\_t* *ae\_id*

  The ID of user for whom this ACL describes access permissions. For entries other than ACL\_USER and ACL\_GROUP, this field should be set to ACL\_UNDEFINED\_ID.

- *acl\_perm\_t* *ae\_perm*

  This field defines what kind of access the process matching this ACL has for accessing the associated file. For POSIX.1e ACLs, the following are valid:

  - ACL\_EXECUTE

    The process may execute the associated file.

  - ACL\_WRITE

    The process may write to the associated file.

  - ACL\_READ

    The process may read from the associated file.

  - ACL\_PERM\_NONE

    The process has no read, write or execute permissions to the associated file.

    For NFSv4 ACLs, the following are valid:

    - ACL\_READ\_DATA

      The process may read from the associated file.

    - ACL\_LIST\_DIRECTORY

      Same as ACL\_READ\_DATA.

    - ACL\_WRITE\_DATA

      The process may write to the associated file.

    - ACL\_ADD\_FILE

      Same as ACL\_ACL\_WRITE\_DATA.

    - ACL\_APPEND\_DATA

      - ACL\_ADD\_SUBDIRECTORY

      Same as ACL\_APPEND\_DATA.

    - ACL\_READ\_NAMED\_ATTRS

      Ignored.

    - ACL\_WRITE\_NAMED\_ATTRS

      Ignored.

    - ACL\_EXECUTE

      The process may execute the associated file.

    - ACL\_DELETE\_CHILD

      - ACL\_READ\_ATTRIBUTES

      - ACL\_WRITE\_ATTRIBUTES

      - ACL\_DELETE

      - ACL\_READ\_ACL

      - ACL\_WRITE\_ACL

      - ACL\_WRITE\_OWNER

      - ACL\_SYNCHRONIZE

      Ignored.

- *acl\_entry\_type\_t* *ae\_entry\_type*

  This field defines the type of NFSv4 ACL entry. It is not used with POSIX.1e ACLs. The following values are valid:

  - ACL\_ENTRY\_TYPE\_ALLOW

    - ACL\_ENTRY\_TYPE\_DENY

    - *acl\_flag\_t* *ae\_flags*

  This field defines the inheritance flags of NFSv4 ACL entry. It is not used with POSIX.1e ACLs. The following values are valid:

  - ACL\_ENTRY\_FILE\_INHERIT

    - ACL\_ENTRY\_DIRECTORY\_INHERIT

    - ACL\_ENTRY\_NO\_PROPAGATE\_INHERIT

    - ACL\_ENTRY\_INHERIT\_ONLY

    - ACL\_ENTRY\_INHERITED

    The ACL\_ENTRY\_INHERITED flag is set on an ACE that has been inherited from its parent. It may also be set programmatically, and is valid on both files and directories.

## SEE ALSO

[acl(3)](/acl/3.md), [vaccess(9)](/vaccess/9.md), [vaccess\_acl\_nfs4(9)](/vaccess_acl_nfs4/9.md), [vaccess\_acl\_posix1e(9)](/vaccess_acl_posix1e/9.md), [VFS(9)](/VFS/9.md), [VOP\_ACLCHECK(9)](/VOP_ACLCHECK/9.md), [VOP\_GETACL(9)](/VOP_GETACL/9.md), [VOP\_SETACL(9)](/VOP_SETACL/9.md)

## AUTHORS

This manual page was written by Robert Watson.