All Products
Search
Document Center

File Storage NAS:Overview

Last Updated:Nov 01, 2024

File Storage NAS (NAS) provides the following access control lists (ACLs) for the Network File System (NFS) protocol: NFSv4 ACLs and Portable Operating System Interface for UNIX (POSIX) ACLs. You can use NFS ACLs to grant permissions on different directories or files to different users and groups. This topic introduces POSIX ACLs and NFSv4 ACLs and describes the usage notes for these ACLs. This topic also describes how to enable the NFS ACL feature in the console.

Background information

Access control and user management are important for enterprise users who need to share files among different users and groups by using a shared file system. To implement access isolation, you need to grant permissions on different directories or files to different users and groups. NAS provides NFS ACLs to meet the requirements. NFS ACLs include NFSv4 ACLs and POSIX ACLs. An ACL consists of one or more access control entries (ACEs) that each grant a user or group one or more permissions to access a file or directory.

You can use the NFSv3 protocol to mount a file system to which NFSv4 ACLs are applied. After the file system is mounted, the NFSv4 ACLs are converted into POSIX ACLs. You can also use the NFSv4 protocol to mount a file system to which POSIX ACLs are applied. After the file system is mounted, the POSIX ACLs are converted into NFSv4 ACLs. However, NFSv4 ACLs and POSIX ACLs are not fully compatible. The interaction between ACLs and the file mode creation mask (umask) is not in an ideal state. NFSv3 file systems do not support locks. Therefore, if you use NFSv4 ACLs, we recommend that you use the NFSv4 protocol to mount file systems and configure only NFSv4 ACLs for the file systems. We recommend that you do not use the umask or POSIX ACLs along with NFSv4 ACLs. For more information about the NAS NFS ACL feature, see Features.

For more information about how to enable the NFS ACL feature for an NFS file system, see Overview.

POSIX ACLs

The NFSv3 protocol implements access control by using the umask. The POSIX ACL feature is an extension to this permission model. You can grant permissions to specific users and groups in addition to the owner, group, and other classes. In a file system, a directory or file can inherit the permissions from its parent directory.

A POSIX ACL consists of a group of ACEs. An ACE specifies the access permissions of a single user or a group of users on an associated object as a combination of read, write, and execute permissions.

An ACE consists of an ACE flag type, an optional ACE flag qualifier, and a set of permissions. Each group of ACEs is separated by three colons (:) in the following format: default:type:permissions.

  • default: directory-inherit

    Identifies the inherited ACEs of a directory. Only directories support this type of ACE.

  • type: ACE flag type

    POSIX ACLs support six types of ACEs, each represented by a single identifier. The value can be only one ACE type.

    ACE type

    Identifier

    Description

    ACL_USER_OBJ

    user:

    The file owner.

    ACL_USER

    user:uid

    The custom user. Example: owner:admini.

    ACL_GROUP_OBJ

    group:

    The user group.

    ACL_GROUP

    group:uid

    The custom user group. Example: group:players.

    ACL_MASK

    mask:

    The maximum ACE permissions of custom users, user groups, and custom user groups.

    ACL_OTHER

    other:

    Other users.

  • permissions

    Permission bit

    Description

    r

    The read permissions.

    w

    The write permissions.

    x

    The permissions to execute files or enter directories.

    -

    No permissions.

    For more information about POSIX ACLs, see acl - Linux man page.

NFSv4 ACLs

The NFSv4 ACL feature is an extension to the NFSv4 protocol. Compared with POSIX ACLs, NFSv4 ACLs provide finer-grained access control.

The ACE of an NFSv4 ACL is in the following format: type:flags:principal:permissions.

  • type: ACE type

    NFSv4 ACLs support four types of ACEs, each represented by a single identifier. The value can be only one ACE type.

    Type

    Identifier

    Description

    Allow

    A

    Allow.

    The allowed ACL.

    Deny

    D

    Deny.

    The denied ACL.

    Audit

    U

    Audit.

    Log all access records that require permissions. One or both of the successful-access and failed-access flags are required. Only some systems support this ACE type.

    Alarm

    L

    Alert.

    Generate a system alert for each access that requires permissions. One or both of the successful-access and failed-access flags are required. Only some systems support this ACE type.

  • flags

    Three types of ACE flags are available: group, inheritance, and administrative.

    Flag

    Identifier

    Description

    group

    g

    The user group.

    directory-inherit

    d

    Directories inherit the ACE.

    Newly created subdirectories inherit the ACE.

    file-inherit

    f

    Files inherit the ACE.

    • Newly created files inherit the ACE, and the inheritance flags are removed from the files.

    • Newly created subdirectories inherit the ACE. If directory-inherit is not specified in the parent ACE, inherit-only is added to the inherited ACE.

    inherit-only

    i

    The ACE is not considered in permissions checks, but it is heritable. However, the "inherit-only" flag is removed from the inherited ACE.

    no-propagate-inherit

    n

    Newly created subdirectories inherit the ACE, and the inheritance flags are removed from the files.

    successful-access

    S

    Trigger an alert when the principal is allowed to perform an operation allowed by permissions. The successful-access and failed-access flags are required.

    failed-access

    F

    Trigger an audit when the principal is prevented from performing an operation allowed by permissions. The successful-access and failed-access flags are required.

  • principal

    The object that can perform operations on a file, such as OWNER@, GROUP@, EVERYONE@, and a specified object.

  • permissions

    Note
    • The default least permission of the OWNER principal is tTnNcCy.

    • The default least permission of the GROUP and EVERYONE principals is tncy.

    NFSv4 ACLs for files

    Permission bit

    Functionality

    Usage notes

    r

    Reads a file.

    None.

    w

    Writes or creates a file.

    The w permission takes effect only if both the w and a permissions are specified.

    a

    Appends data to an existing file.

    The a permission takes effect only if both the w and a permissions are specified.

    x

    Executes a file.

    The x permission takes effect only if both the r and x permissions are specified.

    d

    Deletes a file.

    The d permission is invalid in NFSv4 ACL. If you have the w and x permissions on a parent directory, you can delete the current file regardless of whether the d permission is valid on the file.

    D

    -

    You cannot set the D permission on files. The nfs4_setfacl D command is filtered out by the client.

    t

    Reads the attributes of a file.

    This is one of the four default least permissions. You are not allowed to revoke this permission.

    T

    Modifies the attributes of a file.

    None.

    n

    Reads the named attributes of a file.

    This is one of the four default least permissions. You are not allowed to revoke this permission.

    N

    Modifies the named attributes of a file.

    You cannot modify the named attributes of the files in an NFS file system. The N permission is invalid.

    c

    Reads the ACL of a file.

    This is one of the four default least permissions. You are not allowed to revoke this permission.

    C

    Modifies the ACL of a file.

    None.

    o

    Changes the owner of a file.

    If you have the o permission, you can change the file owner to yourself. However, you cannot change the file owner to others unless you are the root user.

    y

    Allows synchronous access.

    This is one of the four default least permissions. You are not allowed to revoke this permission.

    NFSv4 ACLs for directories

    Permission bit

    Functionality

    Usage notes

    r

    Reads a directory.

    None.

    w

    Creates a file or directory.

    The w permission alone is invalid. The functionalities of the w permission are implemented by the D permission. Therefore, the w permission takes effect only if the D and x permissions are specified.

    a

    Creates a subdirectory.

    The a permission alone is invalid. The functionalities of the a permission are implemented by the D permission. Therefore, the a permission takes effect only if the D and x permissions are specified.

    x

    Enters a directory.

    None.

    d

    Deletes a directory.

    The d permission is invalid in NFSv4 ACL. If you have the w and x permissions on a parent directory, you can delete the current directory regardless of whether the d permission is valid on the subdirectory.

    D

    Deletes a subfile or subdirectory from a directory.

    The D permission takes effect only if the D and X permissions are specified.

    t

    Reads the attributes of a directory.

    This is one of the four default least permissions. You are not allowed to revoke this permission.

    T

    Modifies the attributes of a directory.

    None.

    n

    Reads the named attributes of a directory.

    This is one of the four default least permissions. You are not allowed to revoke this permission.

    N

    Modifies the named attributes of a directory.

    You cannot modify the named attributes of the files in an NFS file system. The N permission is invalid.

    c

    Reads the ACL of a directory.

    This is one of the four default least permissions. You are not allowed to revoke this permission.

    C

    Modifies the ACL of a directory.

    None.

    o

    Changes the owner of a file.

    If you have the o permission, you can change the file owner to yourself. However, you cannot change the file owner to others unless you are the root user.

    y

    Allows synchronous access.

    This is one of the four default least permissions. You are not allowed to revoke this permission.

    For more information about NFSv4 ACLs, see nfs4_acl - Linux man page.

Usage notes for POSIX ACLs

  • Configuration of ACLs

    • We recommend that you use the default method that allows a subdirectory or file to inherit the ACL from the parent directory. Then, you do not need to configure another ACL when you create a new file or subdirectory in the parent directory.

    • Proceed with caution when you configure ACLs by using the recursive method (setfacl -R). A large amount of metadata is generated when you apply an ACL recursively to a directory that contains a large number of files and subdirectories. This may negatively affect your business.

    • Before you configure ACLs, we recommend that you manage groups and the corresponding permissions. For example, you can add a user to one or more groups. To add, remove, or change permissions for a user, you can move the user to a group that has the required permissions. You need to modify the ACL of the group only if the group structure changes. We recommend that you configure ACLs for groups rather than individual users. This is a simple and time-saving method to implement access control.

    • You can apply a POSIX ACL to a user or group that accesses the file system from multiple clients. NAS identifies the user or group based on the user ID (UID) or group ID (GID). Therefore, you must set the same UID or GID for the user or group on the clients.

  • Use of ACLs

    • A file system scans all ACEs each time it performs a permission check. To ensure optimal performance, we recommend that you retain a minimum number of ACEs. If redundant ACLs exist, the performance of the file system degrades.

  • Permissions of the other class

    • All users have the permissions that are granted to the other class. Therefore, we recommend that you grant the least permissions to the other class. If the other class has more permissions than an ACE, a security vulnerability may exist.

    • We recommend that you grant the least permissions to the other class. Before you create files or directories, run the umask 777 command. This command sets the umask to 000 and ensures that the new file or directory has the least permissions. For more information, see umask and the default mode.

    • After you enable the POSIX ACL feature, the other class is moved to the everyone@ user category and the umask is also set. When NAS performs a permission check, NAS treats the other class as everyone.

Usage notes for NFSv4 ACLs

  • Configuration of ACLs

    • Use UIDs or GIDs, such as UID 1001, to configure ACLs.

    • We recommend that you use the default method that allows a subdirectory or a file to inherit the ACL from the parent directory. Then, you do not need to configure another ACL when you create a file or subdirectory in the parent directory.

    • Proceed with caution when you configure ACLs by using the recursive method (nfs4_setfacl -R). A large amount of metadata is generated when you apply an ACL recursively to a directory that contains a large number of files and subdirectories. This may negatively affect your business.

  • Use of ACLs

    • A file system scans all ACEs each time it performs a permission check. To ensure optimal performance, we recommend that you retain a minimum number of ACEs. If redundant ACLs exist, the performance of the file system degrades.

  • ACEs in ACLs

    • We recommend that you do not configure the umask along with NFSv4 ACLs.

    • The nfs4_setfacl command provides multiple options such as the -a, -x, and -m options to add, remove, and modify ACEs. We recommend that you run the nfs4_setfacl -e <file> command to edit an ACL in an editor.

    • NFSv4 ACLs support fine-grained permissions. In most cases, permission control based on fine-grained write permissions is unnecessary. For example, if a user has the write-data (w) access to a file but does not have the append-data (a) access, an error may occur when the user writes data to the file. The same issue occurs for a directory. To prevent unexpected permission errors, we recommend that you specify a capital W when you run the nfs4_setfacl command to configure an ACL. The nfs4_setfacl command specifies full write access. For a file, W is expanded to wadT. For a directory, W is expanded to wadTD.

    • Before you configure ACLs, we recommend that you manage groups and the corresponding permissions. For example, you can add a user to one or more groups. To add, remove, or change permissions for a user, you can move the user to a group that has the required permissions. You need to modify the ACL of the group only if the group structure changes. We recommend that you configure ACLs for groups rather than individual users. This is a simple and time-saving method to implement access control.

    • NAS NFSv4 ACLs support Allow ACEs rather than Deny ACEs. All users have the permissions that are granted to everyone. Therefore, we recommend that you grant the least permissions to everyone. If everyone has more permissions than an ACE, a security vulnerability may exist.

Configure the NFS ACL feature

Use the NAS console

Enable the NFS ACL feature

  1. Log on to the NAS console.

  2. In the left-side navigation pane, choose File System > File System List.

  3. In the top navigation bar, select a region.

  4. On the File System List page, find the file system and click the file system ID or click Manage.in the Actions column.

  5. Click the Access Control tab and click On to enable the NFS ACL feature.NAS_ACL_Open

Disable the NFS ACL feature

On the Access Control tab, click Off (the default state) to disable the NFS ACL feature.

NAS_ACL_Close

Call API operations

  • Call the EnableNfsAcl operation to enable the NFS ACL feature.

  • Call the DisableNfsAcl operation to disable the NFS ACL feature.

After you enable the NFS ACL feature, you can use POSIX ACLs or NFSv4 ACLs to manage file and directory permissions.