HADOOP docker(九):hdfs权限

1. 概述
2. 用户身份标识
3. 组映射
4.关于权限的实现
5.文件系统API的变更
6.应用程序shell的变更
7.超级用户
8.ACLs
9.ACL 文件系统API
10.ACL命令
11.参数配置
12.总结

骚年们，我们今天来学习hdfs的权限~

请忽略4，5两段内容~

文档：http://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html

中文文档参考：http://hadoop.apache.org/docs/r1.0.4/cn/hdfs_permissions_guide.html

1. 概述

hdfs文件系统的权限基于类似POSIX模型来实现的。每个文件和文件夹都和用户和组关联。文件或目录的拥有者、拥有都所在组的用户、其它用户的权限都不同。对于文件,r权限指能读文件，w指能写文件。对于目录，r指能列出目录下的文件，w权限指能创建或者删除目录下的文件\目录,x指能否进入这个目录(读取\执行目录下文件)。

与POSIX模型不同之处是，hdfs上的文件和目录没有setuid和setgid标识位，也没有可执行文件提示。目录可以加上锁标记，防止除superuser、文件或者目录的拥有者 之外的人删除目录中的容易。

HDFS提供了可选的POSIX ACLs功能。

进程在读取HDFS文件时，会被检查用户和组的权限。

2. 用户身份标识

从hadoop0.22开始，支持两种用户身份验证，由参数"hadoop.security.authentication property"决定：

• simple

  由操作系统来决定用户身份，比如linux上的用户

• kerberos

  由kerberos凭证来标识client的身份

3. 组映射

一旦用户的身份决定后，就会把用户映射到一个组，由参数"hadoop.security.group.mapping property"决定。默认配置"org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback"会检查Java Native Interface (JNI)是否存在，如果存在则使用hadoop中的API来解析用户的组。如果JNI不存在，则使用"org.apache.hadoop.security.ShellBasedUnixGroupsMapping"这个配置，通过执行bash -c groups或者net group来解析用户的组

此外，，参数值设为"org.apache.hadoop.security.LdapGroupsMapping"，可以LDAP服务器来解析用户的组。前提是组在LDAP服务器上存在并且与UNIX上的组不混淆。

HDFS上，namenode做用户的组解析工作，因此namenode所在的主机的配置会决定用户的组的解析。

HDFS将用户和组保存在一个文件或者目录中。注意，HDFS不能像在UNIX一样改变用户和组(there is no conversion from user and group identity numbers as is conventional in Unix.)。

4.关于权限的实现

每次文件或目录操作都传递完整的路径名给name node，每一个操作都会对此路径做权限检查。客户框架会隐式地将用户身份和与name node的连接关联起来，从而减少改变现有客户端API的需求。经常会有这种情况，当对一个文件的某一操作成功后，之后同样的操作却会失败，这是因为文件或路径上的某些目录已经不复存在了。比如，客户端首先开始读一个文件，它向name node发出一个请求以获取文件第一个数据块的位置。但接下去的获取其他数据块的第二个请求可能会失败。另一方面，删除一个文件并不会撤销客户端已经获得的对文件数据块的访问权限。而权限管理能使得客户端对一个文件的访问许可在两次请求之间被收回。重复一下，权限的改变并不会撤销当前客户端对文件数据块的访问许可。(引用自http://hadoop.apache.org/docs/r1.0.4/cn/hdfs_permissions_guide.html)

这一段说了一堆的废话，而且是含糊不清的的英文~

5.文件系统API的变更

如果权限检查失败，所有使用路径参数的方法都会抛出AccessControlException异常。

新增加的方法(2.7.3)：

• public FSDataOutputStream create(Path f, FsPermission permission, boolean overwrite, int bufferSize, short replication, long blockSize, Progressable progress) throws IOException;
• public boolean mkdirs(Path f, FsPermission permission) throws IOException;
• public void setPermission(Path p, FsPermission permission) throws IOException;
• public void setOwner(Path p, String username, String groupname) throws IOException;
• public FileStatus getFileStatus(Path f) throws IOException;will additionally return the user, group and mode associated with the path.

新建文件或目录的模式受配置参数umask的约束。当使用之前的 create(path, …) 方法（没有指定权限参数）时，新文件的模式是666?&?^umask。当使用新的 create(path, permission, …) 方法（指定了权限参数P）时，新文件的模式是P?&?^umask?&?666。当使用先前的 mkdirs(path) 方法（没有指定 权限参数）新建一个目录时，新目录的模式是777?&?^umask。当使用新的 mkdirs(path, permission ) 方法（指定了权限参数P）新建一个目录时，新目录的模式是P?&?^umask?&?777。(什么鬼~)

注：本段内容极有可能是某个历史版本文档复制过来的，在hadoop1.04文档中也有这么一段，完全不是新增啊！

6.应用程序shell的变更

略，跟第5段一样，是一堆过时的废话

7.超级用户

超级用户即运行name node进程的用户。宽泛的讲，如果你启动了name node，你就是超级用户。超级用户干任何事情，因为超级用户能够通过所有的权限检查。没有永久记号保留谁过去是超级用户；当name node开始运行时，进程自动判断谁现在是超级用户。HDFS的超级用户不一定非得是name node主机上的超级用户，也不需要所有的集群的超级用户都是一个。同样的，在个人工作站上运行HDFS的实验者，不需任何配置就已方便的成为了他的部署实例的超级用户。

另外，管理员可以用配置参数指定一组特定的用户，如果做了设定，这个组的成员也会是超级用户。

8.ACLs

关于LINUX ACL（http://www.2cto.com/os/201110/108736.html）

默认HDFS不开启ACL，要开启ACL，设置dfs.namenode.acls.enabled＝true

访问控制列表提供了不同于用户和组的权限。一个ACL实体规定的用户\组的权限，如：

   user::rw-
   user:bruce:rwx                  #effective:r--
   group::r-x                      #effective:r--
   group:sales:rwx                 #effective:r--
   mask::r--
   other::r--

这个例子中，文件的拥有都有rx-权限，其所在的组有r-x权限，其它人只的r--权限，因此这个文件的权限是654.此外，用户bruce和sales组对文件有rwx权限。其它用户组有r--权限。mask表示过限制所有group以及命名用户的权限。如bruce group group:sales 被mask后其实只有r权限。mask指定了组和命名用户的最大权限。mask不影响文件的owner和other用户。

上面讲的是"访问ACL"，下面讲"默认ACL"。默认ACL控制子文件\目录的权限。只有目录才能有默认ACL。当在目录下创建文件或者目录时，父目录的默认ACL被当作新创建的文件或者目录的访问ACL，并且子目录也会继承父目录的默认ACL。注意，父目录的默认ACL改变时，已经存在的子文件\目录的ACL不会变。

   user::rwx
   group::r-x
   other::r-x
   default:user::rwx
   default:user:bruce:rwx          #effective:r-x
   default:group::r-x
   default:group:sales:rwx         #effective:r-x
   default:mask::r-x
   default:other::r-x

目录真正的权限，实际是默认ACL结合umask来实现，umask对ACL进行控制。比如默认的umask是022,意思是：目录755，文件644.那么文件的实际权限将是user::rw- 其它全是r--。

一个ACL实体，至少需要三个条目：unnamed user(file owner) unnamed group(file group) other 。当设置默认ACL时，如果没有提供以上的任务一个条目，都会从目录的access ACL中提取相应的，如果没有access ACL，则会读取permission bits。目录的默认ACL，如果没有设置mark，则到ACL中所有的权限的集合。

hdfs上acl验证顺序：

1.如果client提交的用户是文件拥有者 ，验证权限

2.如果client提交的用户是命名的user,验证权限，然后用mark过虑

3.如果client提交的用户在文件所属的组中，验证组权限，然后用mark过滤

4.如果client提交的用户在命名的组中，验证命名组权限，然后用mark过滤

5.如果client提交的用户是属于other，验证other的权限

提示：最佳实践是，用传统的权限管理来管理文件，然后设置对文件设置一些acl。设置acl会对namenode产生额外的开销。

9.ACL 文件系统API

public void modifyAclEntries(Path path, List<AclEntry> aclSpec) throws IOException;
public void removeAclEntries(Path path, List<AclEntry> aclSpec) throws IOException;
public void public void removeDefaultAcl(Path path) throws IOException;
public void removeAcl(Path path) throws IOException;
public void setAcl(Path path, List<AclEntry> aclSpec) throws IOException;
public AclStatus getAclStatus(Path path) throws IOException;

10.ACL命令

hdfs dfs -getfacl [-R] <path>
Displays the Access Control Lists (ACLs) of files and directories. If a directory has a default ACL, then getfacl also displays the default ACL.

hdfs dfs -setfacl [-R] [-b |-k -m |-x <acl_spec> <path>] |[--set <acl_spec> <path>]
Sets Access Control Lists (ACLs) of files and directories.

hdfs dfs -ls <args>
The output of ls will append a ‘+’ character to the permissions string of any file or directory that has an ACL.

具体操作参考hdfs shell.

11.参数配置

12.总结

这主要弄明白：

1.什么是hdfs超级用户？ 启动namenode或者加入dfs.permissions.superusergroup组外，其它的组都是linux上的组(各客户机上的)组的用户

2.hdfs上权限是什么样的？ 类似于linux上的文件系统。除了superusergroup组外，其它的组都是linux上的组(各客户机上的也算)。用户都是各机器上的操作系统用户。

3.hdfs acl 原理

4.权限相关的配置

即可。

来自为知笔记(Wiz)