0%

HDFS ACL 权限管理

发表于 更新于 分类于
本文字数： 3.5k 阅读时长 ≈ 3 分钟
HDFS ACL 权限管理

HDFS 支持 POSIX 访问控制列表（ACLs），以及已支持的传统POSIX权限模型。

前言

ACL 通过给特定命名的 user 和 group 设置不同的权限的方法来控制 HDFS 文件的访问。

ACL的方式增强了传统权限模型，因为它可以让你给任意组合的 user 和 group 来定义访问控制，
而不是为单个 owner/user 或单个 group。

传统的POSIX权限模型

HDFS实现的是类似于POSIX系统的权限模型，如前所述，使用过Linux/Unix系统的用户对该模型应该都非常熟悉，就不再赘述。这里先对下文中最常被问到的问题做一些说明：

  1. 访问某个路径时，用户必须具备该路径上每个目录的执行（x）权限，路径中最后一个目录/文件除外。例如 ls /user/foo/data操作要求用户必须具有根目录(/)，user目录，foo目录的执行权限。

  2. 创建一个文件或者目录时，owner是客户进程的用户，group则继承父目录

  3. 新建文件或目录的模式（mode）由client在rpc调用时传递给NameNode，它受配置参数umask的约束。新文件的模式是666 & ^umask，新目录的模式是777 & ^umask，即文件默认是没有执行(x)权限的。如果在 create(path, permission, …) 方法中指定了权限参数P，新文件的模式是P & ^umask & 666，如果在mkdirs(path, permission ) 方法中指定了权限参数P，新目录的模式是P & ^umask & 777。

例1: 如果umask是022（默认值），那么新文件的模式就是644，新目录的模式就是755，即umask擦除掉了group和other的写权限。

例2: 如果umask是027，那么新文件的模式就是650，新目录的模式就是750，即umask擦除掉了group的写权限，以及other的读写执行权限。

  1. umask通过client端hdfs-site.xml中的fs.permissions.umask-mode配置项来指定，默认是022。

  2. 只有超级用户才可以调用chown来修改目录和文件的owner。

开启 ACL

使用 CM 开启 HDFS 的 ACL。在 HDFS 的配置页面搜索下方参数修改

1
dfs.namenode.acls.enabled

重启相关服务

ACL 条目

一个ACLs由一系列条目（entry）组成，上表表列出了条目的类型及格式，共有六种类型的ACL条目。

最小 ACLs 和扩展 ACLs

最小ACLs就是与文件/目录模式权限位完全对应。

如上图所示，没有附加的权限

hadoop fs -ls 看到什么权限，最小 ACLs 就是这个权限。

拥有超过3个条目的ACLs称为扩展ACLs（extended ACLs）

扩展 ACLs 会包含一个 mask 条目以及给其他指定用户和组授权的条目，
即有名ACL条目（named entry），与最小ACLs中无名条目相对应。

有名 ACL 条目即上表中 ACL 条目中 named user 和 named group 两种类型。

对于最小 ACLs 来说，文件模式权限中的 owner、group 和 other 分别映射到 ACLs owner、owning group 和 others 条目，
对于扩展 ACLs 则是分别映射到 ACLs owner、mask 和 others 条目。

掩码(mask) 影响

在最小 ACLs 中，group class 就是 owning group 条目权限

在扩展 ACLs 中，group class 为 掩码(mask) 条目

除了owner、other 条目以外，其他条目虚与掩码(mask)条目进行与运算，得到最后真实的权限。如下图所示

每一个ACL都有一个掩码(mask)，如果用户不提供掩码，那么该掩码会自动根据所有ACL条目的并集来获得(属主除外）

在该文件上运行 chmod 会改变掩码的权限。由于掩码用于过滤，这有效地限制了权限的扩展 ACL 条目，而不是仅仅改变组条目，并可能丢失的其他扩展ACL条目。

可以看到 mask 为 r-x。user:bigdatams:rwx 条目最后的权限为 #effective:r-x

默认 ACL

前面讨论的ACL条目定义了文件/目录当前的访问权限，称为访问ACLs（access ACLs），另一种类型叫做默认ACLs（default ACL），它定义了当一个文件系统对象被创建时如何从父目录继承权限。

只有目录可以被设置默认ACLs，默认ACLs不会用于权限检查，仅用于权限继承。

创建一个新的目录时，如果父目录设置了默认ACLs，则新目录会继承父目录的默认ACLs作为自己的访问ACLs，同时也作为自己的默认ACLs。

新的文件则只会继承父目录的默认ACLs作为自己的访问ACLs，但文件本身不再有默认ACLs。

从父目录默认 ACLs 继承来的权限并非最终的权限，由于在创建新的目录/文件时 client 一定会传给 NameNode 一个文件模式权限
（见“传统的POSIX权限模型”一节说明3），两者的计算结果才是最终的权限。计算方式采用与运算，即取继承的ACLs中某类权限与模式权限中对应类别权限的交集。

虽然只添加一条默认ACL条目，对于一个完整的ACLs来说所需的其他条目都已经被自动从访问ACLs中复制了过来。

default:mask 也是自动添加的，它的取值是根据所有ACL条目的并集来获得(属主除外）。

权限检查

当一个文件使用ACL时，权限检查的算法则变为:

  • 当用户名为文件的属主时，会检查属主的权限。
  • 否则如果用户名匹配命名用户条目中的一个时，权限会被检查并通过mask权限来进行过滤。
  • 否则如果文件的组匹配到当前用户的组列表中的一个时，而这些权限经过mask过滤后仍然会授权，会被允许使用。
  • 否则如果其中一个命名组条目匹配到组列表中的一个成员，而这些权限经过mask过滤后仍然会授权，会被允许使用。
  • 否则如果文件组和任何命名组条目匹配到组列表中的一个成员时，但是访问不会被任何一个权限所授权时，访问会被拒绝。
  • 除此之外，other权限位会被检查。

使用 ACL

要设置和获取文件的访问控制列表（ACLs），有两种方式API 和 shell。

文件系统的shell命令，setfacl 和 getfacl

1. getfacl
1
2
3
4
5
6
haddop fs -getfacl [-R] <path>

<!-- COMMAND OPTIONS
<path>: 需要列出ACLs的文件或者目录的路径。
-R: 使用递归的方式列出所有文件和目录的ACLs。
-->

2. setfacl

1
2
3
4
5
6
7
8
9
10
11
12
hadoop fs -setfacl [-R] [-b|-k -m|-x <acl_spec> <path>]|[--set <acl_spec> <path>]

<!-- COMMAND OPTIONS
<path>: 需要设置ACLs的文件或者目录的路径。
-R:以递归方式将操作应用于所有文件和目录。
-b: 撤回基本ACL条目以外的所有条目。保留用户，组和其他条目以与权限位兼容。
-k: 移除default ACL。
-m: 修改ACL。新条目将添加到ACL，并保留现有条目。不会影响已有的权限。
-x: 仅移除指定的ACL。
<acl_spec>: 逗号分隔的ACL权限。
--set: 完全替换ACL，丢弃所有现有条目。 acl_spec必须包含用户，组和其他条目，以便与权限位兼容。
-->

总结

当 ls 的权限位输出以+结束时，那么该文件或目录正在启用一个ACL。

常用命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 查询目录的ACL规则
hadoop fs -getfacl /data
 
 
# 递归查询目录的ACL规则
hadoop fs -getfacl -R /data  
 
 
# 为指定user添加权限(user名为hadoop)
hadoop fs -setfacl -m user:hadoop:rwx /data
 
# 为指定group添加权限(group名为group)
hadoop fs -setfacl -m group:hadoop:rwx /data
 
# 删除指定user的ACL规则
hadoop fs -setfacl -x user:hadoop2 /data
 
# 删除所有的ACL规则,但保留基础ACL条目
hadoop fs -setfacl -b /data
 
# 删除默认的ACL规则
hadoop fs -setfacl -k /data
 
#以上加个-R就是对该目录下进行递归操作

参考链接