Cloudera Enterprise 6.0.x | Other versions

HDFS Extended ACLs

HDFS supports POSIX Access Control Lists (ACLs), as well as the traditional POSIX permissions model already supported. ACLs control access of HDFS files by providing a way to set different permissions for specific named users or named groups. They enhance the traditional permissions model by allowing users to define access control for arbitrary combinations of users and groups instead of a single owner/user or a single group.

Enabling HDFS Access Control Lists

By default, HDFS access control lists (ACLs) are disabled on a cluster. You can enable them using either Cloudera Manager or the command line.

    The default ACL applies only to a directory, and all subdirectories and files created in that directory inherit the default ACL of the parent directory.

      For example, if a directory has a default ACL entry of default:group:analysts:rwx, then all files created in the directory get a group:analysts:rwx entry, and subdirectories get both the default ACL and the access ACL copied over. To set a default ACL, simply prepend default: to the user or group entry in the setfacl command (see HDFS Extended ACL Example).

        There is a maximum number/limit of 32 entries in a single HDFS extended ACL. If you attempt to add ACL entries exceeding the maximum of 32, you will get an error. An excessive number of ACL entries indicates that the requirements are better implemented by defining additional groups or users. ACLs with a very high number of entries also require additional memory and storage, and take longer to evaluate upon each permission check.

            Important: Ensure that all users and groups resolve on the NameNode for ACLs to work as expected.

          Enabling HDFS ACLs Using Cloudera Manager

          1. Go to the Cloudera Manager Admin Console and navigate to the HDFS service.
          2. Click the Configuration tab.
          3. Select Scope > Service_name (Service-Wide)
          4. Select Category > Security
          5. Locate the Enable Access Control Lists property and select its checkbox to enable HDFS ACLs.
          6. Enter a Reason for change, and then click Save Changes to commit the changes.

          Commands

          To set and get file access control lists (ACLs), use the file system shell commands, setfacl and getfacl.

          getfacl

          hdfs dfs -getfacl [-R] <path>
          
          <!-- COMMAND OPTIONS
          <path>: Path to the file or directory for which ACLs should be listed.
          -R: Use this option to recursively list ACLs for all files and directories.
          -->
          Examples:
          <!-- To list all ACLs for the file located at /user/hdfs/file -->
          hdfs dfs -getfacl /user/hdfs/file
          
          <!-- To recursively list ACLs for /user/hdfs/file -->
          hdfs dfs -getfacl -R /user/hdfs/file

          setfacl

          hdfs dfs -setfacl [-R] [-b|-k -m|-x <acl_spec> <path>]|[--set <acl_spec> <path>]
          
          <!-- COMMAND OPTIONS
          <path>: Path to the file or directory for which ACLs should be set.
          -R: Use this option to recursively list ACLs for all files and directories.
          -b: Revoke all permissions except the base ACLs for user, groups and others.
          -k: Remove the default ACL.
          -m: Add new permissions to the ACL with this option. Does not affect existing permissions.
          -x: Remove only the ACL specified.
          <acl_spec>: Comma-separated list of ACL permissions.
          --set: Use this option to completely replace the existing ACL for the path specified. 
                 Previous ACL entries will no longer apply.
          -->

          Examples:

          <!-- To give user ben read & write permission over /user/hdfs/file -->
          hdfs dfs -setfacl -m user:ben:rw- /user/hdfs/file
          
          <!-- To remove user alice's ACL entry for /user/hdfs/file -->
          hdfs dfs -setfacl -x user:alice /user/hdfs/file
          
          <!-- To give user hadoop read & write access, and group or others read-only access -->
          hdfs dfs -setfacl --set user::rw-,user:hadoop:rw-,group::r--,other::r-- /user/hdfs/file

          For more information on using HDFS ACLs, see the HDFS Permissions Guide on the Apache website.

          HDFS Extended ACL Example

          This example demonstrates how a user ("alice"), shares folder access with colleagues from another team ("hadoopdev"), so that the hadoopdev team can collaborate on the content of that folder; this is accomplished by updating the default extended ACL of that directory:
          1. Make the files and sub-directories created within the content directory readable by team "hadoopdev":
            $ hdfs bfs -setfacl -m group:hadoopdev:r-x /project
          2. Set the default ACL setting for the parent directory:
            $ hdfs dfs -setfacl -m default:group:hadoopdev:r-x /project
          3. Create a sub-directory for the content you wish to share:
            $ hdfs dfs -mkdir /project/dev
          4. Inspect the new sub-directory ACLs to verify that HDFS has applied the new default values:
            $ hdfs dfs -getfacl -R /project
            
            file: /project
            owner: alice
            group: appdev
            user::rwx
            group::r-x
            other::r-x
            default:user::rwx
            default:group::r-x
            default:group:hadoopdev:r-x
            default:mask::r-x
            default:other::r-x
            
            file: /project/dev
            owner: alice
            group: appdev
            user::rwx
            group::r-x
            group:hadoopdev:r-x
            mask::r-x
            other::r-x
            default:user::rwx
            default:group::r-x
            default:group:hadoopdev:r-x
            default:mask::r-x
            default:other::r-x
            Note: At the time it is created, the default ACL is copied from the parent directory to the child directory. Subsequent changes to the parent directory default ACL do not change the ACLs of the existing child directories.
          Page generated July 25, 2018.