Azure Data Lake Storage Gen1 中的访问控制

Azure Data Lake Storage Gen1 实现一个访问控制模型，该模型派生自 HDFS，后者又派生自 POSIX 访问控制模型。 本文总结了 Data Lake Storage Gen1 访问控制模型的基础知识。

文件和文件夹上的访问控制列表

有两种类型的访问控制列表（ ACL）、访问 ACL 和 默认 ACL。

• 访问 ACL：这些控制对对象的访问。 文件和文件夹都具有 Access ACL。

• 默认 ACL：与文件夹关联的 ACL 的“模板”，用于确定在该文件夹下创建的任何子项的访问 ACL。 文件没有默认 ACL。

Access ACL 和默认 ACL 具有相同的结构。

权限

文件系统对象的权限为 “读取”、“ 写入”和 “执行”，可用于文件和文件夹，如下表所示：

权限的简短形式

RWX 用于表示“读取 + 写入 + 执行”。 还有更精简的数字形式，“读取=4”，“写入=2”，“执行=1”，其总和表示各种不同的权限。 下面是一些示例。

权限不继承

在 Data Lake Storage Gen1 使用的 POSIX 样式模型中，项的权限存储在项本身上。 换句话说，无法从父项继承项的权限。

与权限相关的常见方案

下面是一些常见方案，可帮助你了解在 Data Lake Storage Gen1 帐户上执行某些作所需的权限。

用户和身份

每个文件和文件夹对这些标识具有不同的权限：

• 拥有用户
• 拥有者组
• 命名用户
• 命名的组
• 所有其他用户

用户和组的标识是 Microsoft Entra 标识。 因此，除非另有说明，Data Lake Storage Gen1 上下文中的“用户”可能表示Microsoft Entra 用户或 Microsoft Entra 安全组。

超级用户

超级用户拥有 Data Lake Storage Gen1 帐户中所有用户的最大权限。 超级用户：

• 拥有所有文件和文件夹的 RWX 权限。
• 可以更改任何文件或文件夹的权限。
• 可以更改任何文件或文件夹的所属用户或所属组。

属于 Data Lake Storage Gen1 帐户的 “所有者” 角色的所有用户都是超级用户。

拥有者用户

创建项的用户自动成为该项的拥有用户。 拥有用户可以：

• 更改所拥有文件的权限。
• 更改所拥有文件的拥有组，前提是该拥有用户也是目标组的成员。

所有者组

背景

在 POSIX ACL 中，每个用户都与“主组”相关联。例如，用户“alice”可能属于“finance”组。 Alice 可能也属于多个组，但始终将一个组指定为主要组。 在 POSIX 中，当 Alice 创建文件时，该文件的拥有组设置为她的主组，在本例中为“finance”。否则，拥有组的行为会类似于为其他用户/组分配的权限。

由于 Data Lake Storage Gen1 中没有与用户关联的“主组”，因此将按如下所示分配拥有组。

为新文件或文件夹分配拥有组

• 案例 1：根文件夹“/”。 创建 Data Lake Storage Gen1 帐户时会创建此文件夹。 在这种情况下，拥有组设置为全零 GUID。 此值不允许任何访问。 这是一个占位符，直到分配组。
• 案例 2（其他情况）：创建新项目时，将从父文件夹复制所属组。

更改拥有组

拥有组可以通过以下方式更改：

• 任何超级用户。
• 拥有用户——如果该拥有用户同时是目标组的成员。

访问检查算法

以下伪代码表示 Data Lake Storage Gen1 帐户的访问检查算法。

def access_check( user, desired_perms, path ) : 
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permmissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
      member_count += 1
      perms | =  entry.permissions
  if (member_count>0) :
    return ((desired_perms & perms & mask ) == desired_perms)
 
  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

口罩

如访问检查算法中所述，掩码限制 对命名用户、 拥有组和 命名组的访问。

粘滞位

粘性位是 POSIX 文件系统的更高级功能。 在 Data Lake Storage Gen1 的上下文中，不太可能需要粘滞位。 总之，如果在文件夹中启用了粘滞位，则子项只能由子项的拥有用户删除或重命名。

粘滞位不会显示在 Azure 门户中。

对新文件和文件夹的默认权限

在现有文件夹下创建新文件或文件夹时，父文件夹上的默认 ACL 确定：

• 子文件夹的默认 ACL 和访问 ACL。
• 子文件的访问控制列表（ACL）（文件没有默认访问控制列表）。

umask

创建文件或文件夹时，umask 用于修改在子项上设置默认 ACL 的方式。 umask 是父文件夹中的 9 位值，其中包含用于拥有用户、拥有组和其他的 RWX 值。

Azure Data Lake Storage Gen1 的 umask 是一个被设定为 007 的常量值。 此值转换为

Azure Data Lake Storage Gen1 使用的 umask 值实际上意味着，无论默认 ACL 指示什么，默认情况下，其他值都不会在新的子级上传输。

以下伪代码演示在为子项创建 ACL 时如何应用 umask。

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

Data Lake Storage Gen1 中 ACL 的常见问题

是否必须启用 ACL 的支持？

不是。 在 Data Lake Storage Gen1 帐户中，访问控制始终通过 ACL 开启。

递归删除文件夹及其内容需要哪些权限？

• 父文件夹必须具有 写入 + 执行 权限。
• 要删除的文件夹及其中的每个文件夹都需要 读取 + 写入 + 执行 权限。

文件或文件夹的所有者是谁？

文件或文件夹的创建者将成为所有者。

在创建时，哪个组设置为文件或文件夹的拥有组？

新文件或文件夹所在的父文件夹的拥有组会被复制为新文件或文件夹的拥有组。

我是文件的拥有用户，但我没有所需的 RWX 权限。 我该怎么办？

拥有用户只需更改文件的权限，即可自动获得所需的任何 RWX 权限。

当我在 Azure 门户中查看 ACL 时，我看到用户名，但通过 API，我会看到 GUID，为什么呢？

ACL 中的条目存储为 GUID，这些 GUID 对应于 Microsoft Entra ID 中的用户。 API 按原样返回 GUID。 Azure 门户尝试尽可能将 GUID 转换为友好名称，使 ACL 更易于使用。

为什么在使用 Azure 门户时，我有时会在 ACL 中看到 GUID？

当用户不再存在于 Microsoft Entra 中时，会显示 GUID。 当用户离职，或者其帐户已在 Microsoft Entra ID 中删除时，往往会发生这种情况。 此外，请确保使用正确的 ID 来设置 ACL（有关问题的详细信息见下文）。

使用服务主体时，我应使用什么 ID 来设置 ACL？

在 Azure 门户中，转到 Microsoft Entra ID -> Enterprise 应用程序 并选择应用程序。 “ 概述 ”选项卡应显示对象 ID，这是添加 ACL 进行数据访问（而不是应用程序 ID）时应使用的内容。

Data Lake Storage Gen1 是否支持 ACL 继承？

否，但默认 ACL 可用于为父文件夹下新建的子文件和文件夹设置 ACL。

文件和文件夹上的 ACL 条目有哪些限制？

可以为每个文件和每个目录设置 32 个 ACL。 访问控制列表 (ACL) 和默认访问控制列表 (ACL) 都有各自的 32 个 ACL 条目限制。 尽量使用安全组来进行 ACL 分配。 通过使用组，不太可能超过目录或文件的 ACL 条目数量上限。

在哪里可以了解 POSIX 访问控制模型的详细信息？

• Linux 上的 POSIX 访问控制列表
• HDFS 权限指南
• POSIX FAQ
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• Ubuntu 上的 POSIX ACL

另请参阅

• Azure Data Lake Storage Gen1 概述