Azure Data Lake Storage Gen2 中的访问控制列表 (ACL)Access control lists (ACLs) in Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 实现了一个访问控制模型,该模型支持 Azure 基于角色的访问控制 (Azure RBAC) 和类似 POSIX 的访问控制列表 (ACL)。Azure Data Lake Storage Gen2 implements an access control model that supports both Azure role-based access control (Azure RBAC) and POSIX-like access control lists (ACLs). 本文介绍了 Data Lake Storage Gen2 中的访问控制列表。This article describes access control lists in Data Lake Storage Gen2. 若要了解如何结合使用 Azure RBAC 和 ACL,以及系统如何评估它们以做出授权决策,请参阅 Azure Data Lake Storage Gen2 中的访问控制模型To learn about how to incorporate Azure RBAC together with ACLs, and how system evaluates them to make authorization decisions, see Access control model in Azure Data Lake Storage Gen2.

关于 ACLAbout ACLs

可将安全主体关联到对文件和目录的访问权限级别。You can associate a security principal with an access level for files and directories. 这些关联在访问控制列表 (ACL) 中捕获。These associations are captured in an access control list (ACL). 存储帐户中的每个文件和目录都有一个访问控制列表。Each file and directory in your storage account has an access control list. 当安全主体尝试对文件或目录执行操作时,ACL 检查将确定安全主体(用户、组、服务主体或托管标识)是否具有执行该操作所需的正确权限级别。When a security principal attempts an operation on a file or directory, An ACL check determines whether that security principal (user, group, service principal, or managed identity) has the correct permission level to perform the operation.

备注

ACL 仅应用于同一个租户中的安全主体,不应用于使用共享密钥或共享访问签名 (SAS) 令牌身份验证的用户。ACLs apply only to security principals in the same tenant, and they don't apply to users who use Shared Key or shared access signature (SAS) token authentication. 那是因为没有与调用方关联的标识,因此不能执行基于安全主体权限的授权。That's because no identity is associated with the caller and therefore security principal permission-based authorization cannot be performed.

如何设置 ACLHow to set ACLs

若要设置文件和目录级权限,请参阅以下任一文章:To set file and directory level permissions, see any of the following articles:

环境Environment 项目Article
Azure 存储资源管理器Azure Storage Explorer 使用 Azure 存储资源管理器管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse Azure Storage Explorer to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
.NET.NET 使用 .NET 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse .NET to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
JavaJava 使用 Java 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse Java to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
PythonPython 使用 Python 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse Python to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
PowerShellPowerShell 使用 PowerShell 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse PowerShell to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
Azure CLIAzure CLI 使用 Azure CLI 管理 Azure Data Lake Storage Gen2 中的目录、文件和 ACLUse Azure CLI to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
REST APIREST API 路径 - 更新Path - Update

重要

如果安全主体是服务主体,则必须使用该服务主体的对象 ID,而不能使用相关应用注册的对象 ID。If the security principal is a service principal, it's important to use the object ID of the service principal and not the object ID of the related app registration. 若要获取服务主体的对象 ID,请打开 Azure CLI,然后使用此命令:az ad sp show --id <Your App ID> --query objectIdTo get the object ID of the service principal open the Azure CLI, and then use this command: az ad sp show --id <Your App ID> --query objectId. 请务必将 <Your App ID> 占位符替换为应用注册的应用 ID。make sure to replace the <Your App ID> placeholder with the App ID of your app registration.

ACL 的类型Types of ACLs

访问控制列表有两种类型:访问 ACL 和默认 ACL。 There are two kinds of access control lists: access ACLs and default ACLs.

访问 ACL 控制对某个对象的访问权限。Access ACLs control access to an object. 文件和目录都具有访问 ACL。Files and directories both have access ACLs.

默认 ACL 是与目录关联的 ACL 模板,用于确定在该目录下创建的任何子项的访问 ACL。Default ACLs are templates of ACLs associated with a directory that determine the access ACLs for any child items that are created under that directory. 文件没有默认 ACL。Files do not have default ACLs.

访问 ACL 和默认 ACL 具有相同的结构。Both access ACLs and default ACLs have the same structure.

备注

更改父级的默认 ACL 不影响现有子项的访问 ACL 或默认 ACL。Changing the default ACL on a parent does not affect the access ACL or default ACL of child items that already exist.

权限级别Levels of permission

容器中目录和文件的权限为“读取”、“写入”和“执行”,可对文件和目录使用这些权限,如下表所示: The permissions on directories and files in a container, are Read, Write, and Execute, and they can be used on files and directories as shown in the following table:

文件File DirectoryDirectory
读取 (R)Read (R) 可以读取文件内容Can read the contents of a file 需有“读取”和“执行”权限才能列出目录内容 Requires Read and Execute to list the contents of the directory
写入 (W)Write (W) 可以在文件中写入或追加内容Can write or append to a file 需有“写入”和“执行”权限才能在目录中创建子项 Requires Write and Execute to create child items in a directory
执行 (X)Execute (X) 不表示 Data Lake Storage Gen2 上下文中的任何内容Does not mean anything in the context of Data Lake Storage Gen2 需要遍历目录的子项Required to traverse the child items of a directory

备注

如果仅使用 ACL(不使用 Azure RBAC)授予权限,则要授予安全主体对文件的读取或写入访问权限,需要授予安全主体对容器根文件夹以及通向该文件的文件夹层次结构中每个文件夹的“执行”权限。If you are granting permissions by using only ACLs (no Azure RBAC), then to grant a security principal read or write access to a file, you'll need to give the security principal Execute permissions to the root folder of the container, and to each folder in the hierarchy of folders that lead to the file.

权限的简短形式Short forms for permissions

RWX 用于表示“读取 + 写入 + 执行”。RWX is used to indicate Read + Write + Execute. 还有更精简的数字形式,“读取=4”,“写入=2”,“执行=1”,其总和表示各种不同的权限。 A more condensed numeric form exists in which Read=4, Write=2, and Execute=1, the sum of which represents the permissions. 下面是一些示例。Following are some examples.

数字形式Numeric form 简短形式Short form 含义What it means
77 RWX 读取 + 写入 + 执行Read + Write + Execute
55 R-X 读取 + 执行Read + Execute
44 R-- 读取Read
00 --- 无权限No permissions

权限继承Permissions inheritance

在 Data Lake Storage Gen2 使用的 POSIX 样式的模型中,项的权限存储在项本身中。In the POSIX-style model that's used by Data Lake Storage Gen2, permissions for an item are stored on the item itself. 换而言之,如果是在已创建子项后设置的权限,则不能从父项继承项的权限。In other words, permissions for an item cannot be inherited from the parent items if the permissions are set after the child item has already been created. 只有于创建子项前在父项上设置了默认权限时,才能继承权限。Permissions are only inherited if default permissions have been set on the parent items before the child items have been created.

下表显示了让安全主体执行“操作”列中列出的操作所需的 ACL 条目。The following table shows you the ACL entries required to enable a security principal to perform the operations listed in the Operation column.

此表显示的列代表虚构目录层次结构的每个级别。This table shows a column that represents each level of a fictitious directory hierarchy. 容器的根目录 (\)、名为 Oregon 的子目录、Oregon 目录的名为 Portland 的子目录以及 Portland 目录中名为 Data.txt 的文本文件分别对应一个列。There's a column for the root directory of the container (\), a subdirectory named Oregon, a subdirectory of the Oregon directory named Portland, and a text file in the Portland directory named Data.txt.

重要

此表假设你仅在使用 ACL,没有使用任何 Azure 角色分配。This table assumes that you are using only ACLs without any Azure role assignments. 若要查看组合使用 Azure RBAC 和 ACL 的类似表,请参阅权限表:组合使用 Azure RBAC 和 ACLTo see a similar table that combines Azure RBAC together with ACLs, see Permissions table: Combining Azure RBAC and ACL.

操作Operation / Oregon/Oregon/ Portland/Portland/ Data.txtData.txt
Read Data.txtRead Data.txt --X --X --X R--
Append to Data.txtAppend to Data.txt --X --X --X RW-
Delete Data.txtDelete Data.txt --X --X -WX ---
Create Data.txtCreate Data.txt --X --X -WX ---
List /List / R-X --- --- ---
List /Oregon/List /Oregon/ --X R-X --- ---
List /Oregon/Portland/List /Oregon/Portland/ --X --X R-X ---

备注

只要以上两个条件成立,删除文件时就不需要文件的写入权限。Write permissions on the file are not required to delete it, so long as the previous two conditions are true.

用户和标识Users and identities

每个文件和目录都有这些标识的不同权限:Every file and directory has distinct permissions for these identities:

  • 拥有用户The owning user
  • 拥有组The owning group
  • 命名用户Named users
  • 命名组Named groups
  • 命名服务主体Named service principals
  • 命名托管标识Named managed identities
  • 所有其他用户All other users

用户和组的标识是 Azure Active Directory (Azure AD) 标识。The identities of users and groups are Azure Active Directory (Azure AD) identities. 因此,除非另有规定,否则“用户”在 Data Lake Storage Gen2 的上下文中可以表示 Azure AD 用户、服务主体、托管标识或安全组。So unless otherwise noted, a user, in the context of Data Lake Storage Gen2, can refer to an Azure AD user, service principal, managed identity, or security group.

拥有用户The owning user

创建项的用户自动成为该项的拥有用户。The user who created the item is automatically the owning user of the item. 拥有用户可以:An owning user can:

  • 更改所拥有文件的权限。Change the permissions of a file that is owned.
  • 更改所拥有文件的拥有组,前提是该拥有用户也是目标组的成员。Change the owning group of a file that is owned, as long as the owning user is also a member of the target group.

备注

拥有用户无法更改某个文件或目录的拥有用户。The owning user cannot change the owning user of a file or directory. 只有超级用户可以更改文件或目录的拥有用户。Only super-users can change the owning user of a file or directory.

拥有组The owning group

在 POSIX ACL 中,每个用户都与“主组”关联。In the POSIX ACLs, every user is associated with a primary group. 例如,用户“Alice”可能属于“finance”组。For example, user "Alice" might belong to the "finance" group. Alice 还可能属于多个组,但始终有一个组指定为她的主组。Alice might also belong to multiple groups, but one group is always designated as their primary group. 在 POSIX 中,当 Alice 创建文件时,该文件的拥有组设置为她的主组,在本例中为“finance”。In POSIX, when Alice creates a file, the owning group of that file is set to her primary group, which in this case is "finance." 否则,所有者组的行为类似于为其他用户/组分配的权限。The owning group otherwise behaves similarly to assigned permissions for other users/groups.

为新的文件或目录分配拥有组Assigning the owning group for a new file or directory

  • 情况 1:根目录“/”。Case 1: The root directory "/". 此目录是在创建 Data Lake Storage Gen2 容器时创建的。This directory is created when a Data Lake Storage Gen2 container is created. 在这种情况下,如果容器是使用 OAuth 创建的,则拥有组将设置为创建容器的用户。In this case, the owning group is set to the user who created the container if it was done using OAuth. 如果容器是使用共享密钥、帐户 SAS 或服务 SAS 创建的,则所有者和拥有组将设置为 $superuser。If the container is created using Shared Key, an Account SAS, or a Service SAS, then the owner and owning group are set to $superuser.
  • 情况 2(所有其他情况):创建新项时,从父目录复制拥有组。Case 2 (Every other case): When a new item is created, the owning group is copied from the parent directory.

更改拥有组Changing the owning group

拥有组可由以下用户更改:The owning group can be changed by:

  • 任何超级用户。Any super-users.
  • 拥有用户,前提是该拥有用户也是目标组的成员。The owning user, if the owning user is also a member of the target group.

备注

拥有组无法更改某个文件或目录的 ACL。The owning group cannot change the ACLs of a file or directory. 虽然拥有组设置为在根目录那一种情况(即上面的 案例 1)中创建了帐户的用户,但单个用户帐户不能有效地用于通过拥有组提供权限。While the owning group is set to the user who created the account in the case of the root directory, Case 1 above, a single user account isn't valid for providing permissions via the owning group. 可以将此权限分配给有效的用户组(如果适用)。You can assign this permission to a valid user group if applicable.

访问检查算法Access check algorithm

以下伪代码显示了存储帐户的访问检查算法。The following pseudocode represents the access check algorithm for storage accounts.

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 directory
  # Note: the "sticky bit" isn't illustrated in this algorithm
  
  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't 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.permissions & mask) == desired_perms)

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

掩码The mask

如访问检查算法中所示,掩码会限制对命名用户、拥有组和命名组的访问权限。As illustrated in the Access Check Algorithm, the mask limits access for named users, the owning group, and named groups.

对于新的 Data Lake Storage Gen2 容器,根目录(“/”)的访问 ACL 的掩码默认为 750(适用于目录)和 640(适用于文件)。For a new Data Lake Storage Gen2 container, the mask for the access ACL of the root directory ("/") defaults to 750 for directories and 640 for files. 下表显示了这些权限级别的符号表示法。The following table shows the symbolic notation of these permission levels.

实体Entity 目录Directories 文件Files
拥有用户Owning user rwx r-w
拥有组Owning group r-x r--
其他Other --- ---

文件不接收 X 位,因为它与只存储系统中的文件无关。Files do not receive the X bit as it is irrelevant to files in a store-only system.

可能会在每次调用时指定掩码。The mask may be specified on a per-call basis. 这就使不同的使用系统(例如群集)能够为文件操作使用不同的有效掩码。This allows different consuming systems, such as clusters, to have different effective masks for their file operations. 如果根据特定请求指定了掩码,则该掩码完全替代默认掩码。If a mask is specified on a given request, it completely overrides the default mask.

粘滞位The sticky bit

粘滞位是 POSIX 容器的更高级功能。The sticky bit is a more advanced feature of a POSIX container. 在 Data Lake Storage Gen2 的上下文中,不太可能需要粘滞位。In the context of Data Lake Storage Gen2, it is unlikely that the sticky bit will be needed. 总之,如果目录上已启用粘滞位,子项只能由子项的拥有用户删除或重命名。In summary, if the sticky bit is enabled on a directory, a child item can only be deleted or renamed by the child item's owning user.

粘滞位不会显示在 Azure 门户中。The sticky bit isn't shown in the Azure portal.

新文件和目录的默认权限Default permissions on new files and directories

在现有目录下创建新文件或目录时,父目录的默认 ACL 会确定:When a new file or directory is created under an existing directory, the default ACL on the parent directory determines:

  • 子目录的默认 ACL 和访问 ACL。A child directory's default ACL and access ACL.
  • 子文件的访问 ACL(文件没有默认 ACL)。A child file's access ACL (files do not have a default ACL).

umaskumask

创建文件或目录时,umask 用于修改默认 ACL 在子项上的设置方式。When creating a file or directory, umask is used to modify how the default ACLs are set on the child item. umask 是父目录上一个 9 位的值,它包含“拥有用户”、“拥有组”和“其他”的 RWX 值 。umask is a 9-bit value on parent directories that contains an RWX value for owning user, owning group, and other.

Azure Data Lake Storage Gen2 的 umask 是设置为 007 的常量值。The umask for Azure Data Lake Storage Gen2 a constant value that is set to 007. 此值将转换为:This value translates to:

umask 组件umask component 数字形式Numeric form 简短形式Short form 含义Meaning
umask.owning_userumask.owning_user 00 --- 对于拥有用户,将父项的默认 ACL 复制到子项的访问 ACLFor owning user, copy the parent's default ACL to the child's access ACL
umask.owning_groupumask.owning_group 00 --- 对于拥有组,将父项的默认 ACL 复制到子项的访问 ACLFor owning group, copy the parent's default ACL to the child's access ACL
umask.otherumask.other 77 RWX 对于其他,删除子项的访问 ACL 的所有权限For other, remove all permissions on the child's access ACL

Azure Data Lake Storage Gen2 使用的 umask 值实际上表示默认情况下永远不会在新子项上传输“other”的值,除非在父目录上定义了默认的 ACL。The umask value used by Azure Data Lake Storage Gen2 effectively means that the value for other is never transmitted by default on new children, unless a default ACL is defined on the parent directory. 在这种情况下,umask 实际上会被忽略,默认 ACL 定义的权限将应用于子项。In that case, the umask is effectively ignored and the permissions defined by the default ACL are applied to the child item.

以下伪代码显示了在为子项创建 ACL 时如何应用 umask。The following pseudocode shows how the umask is applied when creating the ACLs for a child item.

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 )

常见问题解答FAQ

是否必须启用 ACL 的支持?Do I have to enable support for ACLs?

否。No. 只要开启了分层命名空间 (HNS) 功能,存储帐户就能通过 ACL 进行访问控制。Access control via ACLs is enabled for a storage account as long as the Hierarchical Namespace (HNS) feature is turned ON.

如果关闭了 HNS 功能,Azure RBAC 授权规则仍适用。If HNS is turned OFF, the Azure Azure RBAC authorization rules still apply.

应用 ACL 的最佳方式是什么?What is the best way to apply ACLs?

始终将 Azure AD 安全组用作 ACL 条目中分配的主体。Always use Azure AD security groups as the assigned principal in an ACL entry. 拒绝直接分配各个用户或服务主体。Resist the opportunity to directly assign individual users or service principals. 使用此结构,你可以添加和删除用户或服务主体,不需要向整个目录结构重新应用 ACL。Using this structure will allow you to add and remove users or service principals without the need to reapply ACLs to an entire directory structure. 可以仅在适当的 Azure AD 安全组中添加或删除用户和服务主体。Instead, you can just add or remove users and service principals from the appropriate Azure AD security group.

有多种不同的方法可用来设置组。There are many different ways to set up groups. 例如,假设你有一个名为 /LogData 的目录,该目录包含服务器生成的日志数据。For example, imagine that you have a directory named /LogData which holds log data that is generated by your server. Azure 数据工厂 (ADF) 将数据引入到该文件夹中。Azure Data Factory (ADF) ingests data into that folder. 服务工程团队中的特定用户将上传日志并管理此文件夹的其他用户,而各个 Databricks 群集将分析来自该文件夹的日志。Specific users from the service engineering team will upload logs and manage other users of this folder, and various Databricks clusters will analyze logs from that folder.

若要启用这些活动,可以创建一个 LogsWriter 组和一个 LogsReader 组。To enable these activities, you could create a LogsWriter group and a LogsReader group. 然后,可以按如下所示分配权限:Then, you could assign permissions as follows:

  • LogsWriter 组添加到 /LogData 目录的具有 rwx 权限的 ACL。Add the LogsWriter group to the ACL of the /LogData directory with rwx permissions.
  • LogsReader 组添加到 /LogData 目录的具有 r-x 权限的 ACL。Add the LogsReader group to the ACL of the /LogData directory with r-x permissions.
  • LogsWriters 组添加用于 ADF 的服务主体对象或托管服务标识 (MSI)。Add the service principal object or Managed Service Identity (MSI) for ADF to the LogsWriters group.
  • 将服务工程团队中的用户添加到 LogsWriter 组。Add users in the service engineering team to the LogsWriter group.
  • 将 Databricks 的服务主体对象或 MSI 添加到 LogsReader 组。Add the service principal object or MSI for Databricks to the LogsReader group.

如果服务工程团队中的用户离开了公司,则只需将其从 LogsWriter 组中删除即可。If a user in the service engineering team leaves the company, you could just remove them from the LogsWriter group. 如果未将该用户添加到组中,而是为该用户添加了专用 ACL 条目,则必须从 /LogData 目录中删除此 ACL 条目。If you did not add that user to a group, but instead, you added a dedicated ACL entry for that user, you would have to remove that ACL entry from the /LogData directory. 还必须从 /LogData 目录的整个目录层次结构中的所有子目录和文件中删除此条目。You would also have to remove the entry from all subdirectories and files in the entire directory hierarchy of the /LogData directory.

若要创建组并添加成员,请参阅使用 Azure Active Directory 创建基本组并添加成员To create a group and add members, see Create a basic group and add members using Azure Active Directory.

如何评估 Azure RBAC 和 ACL 权限?How are Azure RBAC and ACL permissions evaluated?

若要了解系统如何将 Azure RBAC 和 ACL 一起评估,以便针对存储帐户资源做出授权决策,请参阅如何评估权限To learn how the system evaluates Azure RBAC and ACLs together to make authorization decisions for storage account resources, see How permissions are evaluated.

Azure 角色限制和 ACL 条目存在哪些限制?What are the limits for Azure role assignments and ACL entries?

下表提供了在使用 Azure RBAC 管理“粗粒度”权限(应用于存储帐户或容器的权限)以及使用 ACL 管理“细粒度”权限(应用于文件和目录的权限)时要考虑的限制的汇总视图。The following table provides a summary view of the limits to consider while using Azure RBAC to manage "coarse-grained" permissions (permissions that apply to storage accounts or containers) and using ACLs to manage "fine-grained" permissions (permissions that apply to files and directories). 使用安全组进行 ACL 分配。Use security groups for ACL assignments. 通过使用组,你不太可能超出每个订阅的角色分配的最大数量,以及每个文件或目录的 ACL 条目的最大数量。By using groups, you're less likely to exceed the maximum number of role assignments per subscription and the maximum number of ACl entries per file or directory.

机制Mechanism 范围Scope 限制Limits 支持的权限级别Supported level of permission
Azure RBACAzure RBAC 存储帐户、容器。Storage accounts, containers.
在订阅或资源组级别进行跨资源 Azure 角色分配。Cross resource Azure role assignments at subscription or resource group level.
一个订阅中 2000 个 Azure 角色分配2000 Azure role assignments in a subscription Azure 角色(内置或自定义)Azure roles (built-in or custom)
ACLACL 目录、文件Directory, file 每个文件和每个目录有 32 个 ACL 条目(实际上是 28 个 ACL 条目)。32 ACL entries (effectively 28 ACL entries) per file and per directory. 访问 ACL 和默认 ACL 都有自己的 32 个 ACL 条目的限制。Access and default ACLs each have their own 32 ACL entry limit. ACL 权限ACL permission

Data Lake Storage Gen2 是否支持 Azure RBAC 继承?Does Data Lake Storage Gen2 support inheritance of Azure RBAC?

Azure 角色分配确实可以继承。Azure role assignments do inherit. 分配从订阅、资源组和存储帐户资源向下传递到容器资源。Assignments flow from subscription, resource group, and storage account resources down to the container resource.

Data Lake Storage Gen2 是否支持 ACL 继承?Does Data Lake Storage Gen2 support inheritance of ACLs?

可以使用默认 ACL 来设置父目录下创建的新子目录和文件的 ACL。Default ACLs can be used to set ACLs for new child subdirectories and files created under the parent directory. 若要更新现有子项的 ACL,你需要以递归方式为所需的目录层次结构添加、更新或删除 ACL。To update ACLs for existing child items, you will need to add, update, or remove ACLs recursively for the desired directory hierarchy. 有关详细信息,请参阅以递归方式为 Azure Data Lake Storage Gen2 设置访问控制列表 (ACL)For more information, see Set access control lists (ACLs) recursively for Azure Data Lake Storage Gen2.

以递归方式删除目录及其内容需要哪些权限?Which permissions are required to recursively delete a directory and its contents?

  • 调用方需要拥有“超级用户”权限,The caller has 'super-user' permissions,

Or

  • 父目录必须拥有“写入 + 执行”权限。The parent directory must have Write + Execute permissions.
  • 要删除的目录及其中的每个目录都需要“读取 + 写入 + 执行”权限。The directory to be deleted, and every directory within it, requires Read + Write + Execute permissions.

备注

删除目录中的文件不需要具有“写入”权限。You do not need Write permissions to delete files in directories. 另外,永远无法删除根目录“/”。Also, the root directory "/" can never be deleted.

谁是文件或目录的所有者?Who is the owner of a file or directory?

文件或目录的创建者就是所有者。The creator of a file or directory becomes the owner. 就根目录而言,这就是创建容器的用户的标识。In the case of the root directory, this is the identity of the user who created the container.

创建文件或目录时将哪个组设置为其拥有组?Which group is set as the owning group of a file or directory at creation?

拥有组是从创建新文件或目录的父目录的拥有组复制而来的。The owning group is copied from the owning group of the parent directory under which the new file or directory is created.

我是文件的拥有用户,但没有所需的 RWX 权限,I am the owning user of a file but I don't have the RWX permissions I need. 我该怎么办?What do I do?

拥有用户只需更改文件的权限,即可自动获得所需的任何 RWX 权限。The owning user can change the permissions of the file to give themselves any RWX permissions they need.

为什么我时候在 ACL 中看到了 GUID?Why do I sometimes see GUIDs in ACLs?

如果条目表示一个用户且该用户不再位于 Azure AD 中,则显示 GUID。A GUID is shown if the entry represents a user and that user doesn't exist in Azure AD anymore. 当用户离职,或者其帐户已在 Azure AD 中删除时,往往会发生这种情况。Usually this happens when the user has left the company or if their account has been deleted in Azure AD. 此外,服务主体和安全组没有用于标识它们的用户主体名称 (UPN),因此用它们的 OID 属性(即一个 GUID)来表示它们。Additionally, service principals and security groups do not have a User Principal Name (UPN) to identify them and so they are represented by their OID attribute (a guid).

如何为服务主体正确设置 ACL?How do I set ACLs correctly for a service principal?

为服务主体定义 ACL 时,必须使用所创建应用注册的服务主体的对象 ID (OID)。When you define ACLs for service principals, it's important to use the Object ID (OID) of the service principal for the app registration that you created. 请务必注意,注册的应用在特定的 Azure AD 租户中具有独立的服务主体。It's important to note that registered apps have a separate service principal in the specific Azure AD tenant. 注册的应用会在 Azure 门户中显示一个 OID,但服务主体具有另一个(不同的)OID。Registered apps have an OID that's visible in the Azure portal, but the service principal has another (different) OID.

若要获取服务主体的对应于应用注册的 OID,可以使用 az ad sp show 命令。To get the OID for the service principal that corresponds to an app registration, you can use the az ad sp show command. 指定应用程序 ID 作为参数。Specify the Application ID as the parameter. 以下示例获取服务主体的 OID,该 OID 对应于应用 ID 为 18218b12-1895-43e9-ad80-6e8fc1ea88ce 的应用注册。Here's an example on obtaining the OID for the service principal that corresponds to an app registration with App ID = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. 在 Azure CLI 中运行以下命令:Run the following command in the Azure CLI:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

随即显示 OID。OID will be displayed.

获取服务主体的正确 OID 后,转到存储资源管理器的“管理访问权限”页,以添加该 OID 并为其分配适当的的权限。When you have the correct OID for the service principal, go to the Storage Explorer Manage Access page to add the OID and assign appropriate permissions for the OID. 请务必选择“保存”。Make sure you select Save.

是否可以设置容器的 ACL?Can I set the ACL of a container?

错误。No. 容器没有 ACL。A container does not have an ACL. 但是,你可以设置容器的根目录的 ACL。However, you can set the ACL of the container's root directory. 每个容器都有一个根目录,该目录与容器同名。Every container has a root directory, and it shares the same name as the container. 例如,如果将容器命名为 my-container,则根目录名为 myContainer/For example, if the container is named my-container, then the root directory is named myContainer/.

Azure 存储 REST API 包含一个名为设置容器 ACL 的操作,但该操作不能用来设置容器或容器根目录的 ACL,The Azure Storage REST API does contain an operation named Set Container ACL, but that operation cannot be used to set the ACL of a container or the root directory of a container. 而只能用来指示容器中的 blob 是否可以公开访问Instead, that operation is used to indicate whether blobs in a container may be accessed publicly.

在哪里可以了解 POSIX 访问控制模型的详细信息?Where can I learn more about POSIX access control model?

另请参阅See also