最近一直在测试HDFS的权限相关的内容，基本上把常用的权限控制方式和流程都过了一遍，所以通过写一篇文档总体梳理归纳一下

HDFS对于文件和目录的权限模型基本是基于POSIX模型，其核心模型主要包括：

  • 文件/目录：在POSIX/Linux文件系统中，文件或者目录都是Inode
  • 角色：角色（principal）是维护和操作系统的用户所持有的权限的集合，主要有Inode的持有者（user，u）、持有者所在的用户组（group，g)以及其他角色（other,o)
  • 权限掩码（mode）：为了简单准确的分辨权限，POSIX一共有3种权限，分别是读（read/r）、写（write/w）和执行（execute/e），这些权限通过一个8进制的数字作为掩码对不同的角色进行区分，并有一个特别的粘滞位标记（StickBit）用来避免误删，给与不同的角色不同的权限掩码，即POSIX/Linux中的基础权限控制机制
  • ACL：权限掩码只能解决单个单个用户/用户组的权限隔离，在多用户/用户组系统种，需要通过ACL来进行扩展支持不同的用户和用户组，其工作模式和权限掩码类似

上述这些核心模型的的有机组装编排，就是整个HDFS的权限的基石

角色

Hadoop主要通过UserGroupInformation对角色进行维护，其中最主要的包括：

  • 超级用户/用户组：超级用户（super-user)是HDFS整个系统中的最高权限，可以通过任何权限检测，默认情况下一般是启动NameNode的系统用户，当然可以通过其他配置（例如Kerberos）指定超级用户，超级用户不一定是HDFS运行的服务器上的系统用户，甚至不同的节点都可以允许不同的超级用户。同时HDFS还可以配置一个超级用户组（super-user group，默认名位supergroup)，隶属于这个组的所有成员也都会被判定为超级用户
  • 用户/用户组映射：不论是普通亦或是超级用户或者用户组，都是HDFS内部的控制概念，HDFS本身并不具体维护任何用户/用户组的具体信息，所有的用户或者用户组均来自外部的映射
    • 用户映射：HDFS的用户来源于JVM通过认证的用户的principal，主要有两个：本地用户和Kerberos认证，在运行时中JVM本身持有启动进程用户的principal，如果不做额外配置就会默认使用UserGroupInformation中的LoginModule（LoginModule是Java Authentication Authorization Service，JAAS的用户认证规范的核心接口）实现获取这个principal。如果用户配置了Kerberos则HDFS会使用Krb5LoginModule进行Kerberos的认证并获取Kerberos的principal作为用户
    • 用户组映射：基于超级用户组的设定，HDFS还需要判定用户是否隶属于超级用户组，所以需要通过一个机制来获取用户隶属的用户组。HDFS默认提供基于操作系统的用户组（默认实现，JniBasedUnixGroupsMappingWithFallback，调用jni获取操作系统的用户组信息，如果失败则使用shell）、LDAP（LdapGroupsMapping，通过LDAP协议远程获取用户组信息）、shell（ShellBasedUnixGroupsMapping，通过执行脚本获取用户组信息）等集中实现，用户也可以自己实现自己的用户组映射方式

权限掩码

权限掩码是整个校验的核心，所有的权限配置最终都会映射到角色是否通过掩码校验来判定是否拥有某个权限。POSIX源码主要有如下特征：

  • 权限一共有三种，分别是r/w/e并且在使用中通过二进制作为掩码并严格排序进行过滤，如果拥有权限则用使用对应的权限标记而如果没有则用-表示，例如拥有所有权限则为rwe，没有任何权限则为—，

权限掩码

  • 在基础权限中，任何Inode针对持有者（user，owner，u）/持有者所在组（group，g）/其他角色（other，o）三个觉得都分别配置了各自的权限掩码，即每个文件有有严格排序的三组权限掩码分别对应u/g/o来进行权限的表达，例如rwxrwxrwx则表示o/g/i都拥有所有权限
  • stickBit是用来对目录（对于文件无效）进行标记来避免用户误删的机制，具有这个标记的目录或者目录下的文件只有owner或者superuser可以删除，stickBit本身是一个特殊的权限掩码，所以整个Inode的权限掩码可以理解为一个10个位的二进制掩码，从左到右第1个位是stickBit，后面9个位分别是u/g/o的3位权限标记

ACL的扩展

为了弥补基础权限只能设置u/g/o三种角色的权限，HDFS默认是开启了ACL来支持多用户/用户组的权限规则设置。

ACL生效是基于在单个Inode上的不同ACL entry的规则配置，每个ACL entry都包含如下内容：

  • type: 枚举类型，这条ACL的规则是针对user还是group
  • name：user或者group的name
  • permission：具体的权限掩码，按照rwx掩码规则
  • scope：标记是否位默认acl规则，只有当用户配置过独立的ACL规则后，才会启用ACL权限校验的流程

权限校验

  • Owner/Group/Other角色：每个Inode都有一个Owner表示文件的归属，拥有文件的最高权限，同时也有一个group，可以单独指派全选，除了Owner和Group的均为Other