HDFS权限管理指南（HDFS Permissions Guide）

综述

HDFS实现了一个类似POSIX模型的文件和文件夹权限管理模型。每一个文件盒文件夹都有一个所有者和一个组。文件或者文件夹可以通过权限区分是所有者还是组成员或是其他用户。对文件来说，r标示可以阅读文件，w标示可以写入文件，对于文件夹来说，r标示可以阅读其下的内容，w可以创建或者删除文件或文件夹，x标示进入其子节点。

与POSIX 模型相比，没有可执行文件的概念，对于文件夹来说，没有setuid或setgid字节也是一个简化，Sticky bit被设置在文件中防止除了超级用户和文件所有者的其他用户删除或者移动文件夹，一个文件被设置成Sticky bit没有影响，总的来说，HDFS的权限系统有自己的独立性。一般来说Unix习惯的显示模型会被使用，包括使用八进制进行描述。当一个文件或者文件夹被创建时，他的所有者就是被客户端进程声明的用户，他的组四父文件夹的组（BSD规则）

每一个客户端访问HDFS都有两个标示部分包括用户名和组列表。每此当客户端进程接入文件或者文件夹时，HDFS必须做一个权限检查。

如果用户名和文件的所有者一直那么就可以使用所有者权限，如果组一致，那么可以使用组的权限，否则使用其他权限。

如果权限没有通过，那么客户端操作失败。

用户识别
Hadoop支持两种操作用于用户识别。不同点是通过配置hadoop.security.authentication属性：

simple

在这种模式下,客户端进程的身份是由主机操作系统决定的。类似unix系统上,用户名相当于“whoami”。

kerberos

使用Kerberized操作，使用客户端的Kerberos证书来确定客户端的进程的身份，比如在Kerberized环境中，用户使用kinit工具实用程序获得Kerberos ticket-granting-ticket(TGT)和使用klist来确定当前的用户。当Kerberos主体映射到一个HDFS用户名时，其他一些非必要的组件会被忽略。比如，一个用户todd/foobar@CORP.COMPANY.COM可以使用todd来登录HDFS。

无论哪种机制，用户标示都是HDFS机制外实现的。HDFS本事没有提供创建用户标示，组或者处理用户凭证的机制。

组映射
一旦用户名被以上的方式确定下来，组列表也会被配置在hadoop.security.group.mapping的参数group mapping service确定下来默认实现是org.apache.hadoop.security.ShellBasedUnixGroupsMapping，他是通过Unix的shell中的-c groups命令解决的用户的组的问题。

如果使用的是LDAP那么可以使用org.apache.Hadoop.security.LdapGroupsMapping。但是这个只能使用在LDAP上不能使用在Unix server上更多的细节可以参考Javadocs中的配置group mapping service的部分

对于HDFS来说，映射用户到组在NameNode上已经实现，主机系统配置NameNode的用户决定了这个组。

注意：HDFS用字符串储存用户和文件和文件夹组，他并没有想Unix一样使用一个标示数字来表示用户和组。

实现
每个文件或者文件夹传递他的全路径到name node，每次操作的时候都需要检查权限。客户端将会隐试的连接name node使用用户标示，减少对于现有的客户端的API改变。因为路劲的改变或者删除会引起有一些操作以前成功，但是在运行的时候失败。比如，当一个客户端第一次读取一个文件，他会发送请求到name node发现文件第一个块的位置。第二个请求去查询其他块可能失败。另一方面，客户端已经知道了文件block使得删除中的文件不能被撤回。通过添加权限客户端取得文件时可以在request之间取消，改变去请您先不会撤销客户端一只的块。
改动的API
下面的方法添加了一个路径的参数并且如果权限检查失败会抛出一个AccessControlException 的异常：

方法：

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;

将返回用户组和路径

该模型建立文件或者文件夹受限于umask的配置参数。当已经存在的方法create(path, …) （没有权限参数）被调用，新文件的模型是 0666 & ^umask，当新方法create(path, permission, …)（权限参数为P）被调用，那么新文件的模型是 P & ^umask & 0666。当创建一个新目录使用现有 mkdirs(path) 方法(没有权限参数),新目录的模式是0777 & ^ umask。当使用mkdirs(path, permission)（权限参数为P），那么新文件测模型是 P & ^umask & 0777。

shell的改变

新的操作：

chmod [-R] mode file …

只有文件的所有者或者超级用户有权限去改变文件的mode

chgrp [-R] group file …

用户调用chgrp 指定属于的组，文件所有者或者超级用户修改。

chown [-R] [owner][:[group]] file …

改变文件的所有者，只能有超级用户修改

ls file …
lsr file …

输出文件所有者组和模式
超级用户

超级用户是name弄得进程使用的用户。更确切的说，就是你启动namenode那么你就是超级用户。超级用户的权限检查永远不会失败，所以可以干任何事情。没有固定的超级用户，当谁启动namenode谁就是超级用户。HDFS的超级用户不是namenode主机的超级用户，没有必要，但是他是所有集群的超级用户。此外,HDFS的实验者在个人工作站,方便就安装的超级用户没有任何配置。

此外管理员可以通过配置参数确定一个高级的组，这个组的成员也是超级用户。

web服务
默认情况下，web服务器的身份是一个配置参数。name node没有真实用户身份的概念，但是web server需要有一个管理员设定的用户和组的标示。除非选择的超级用户不能进入部分的web server。

配置参数

dfs.permissions = true

如果使用yes，标示使用权限系统，如果是no，则关闭权限检查。但是其他的行为不会被改变。切换参数不会改变文件的mode，组和所有者。不管权限是否打开 chmod, chgrp和chown总是检查权限， 这些函数只对权限上下文有作用所以没有版本兼容问题。此外这允许管理员设置所有者开启权限检查功能

dfs.web.ugi = webuser,webgroup

web server的用户名，设置超级用户的名称可以允许任何web客户端看到的一切。逗号分隔。

dfs.permissions.superusergroup = supergroup

超级用户组的名字
fs.permissions.umask-mode = 0022

建文件或者文件夹时使用的umask 。配置文件可以使用十进制的18.
dfs.cluster.administrators = ACL-for-admins

集群的管理员指定为ACL。这可以控制访问默认的servlet等

转载：http://blog.csdn.net/duheaven/article/details/17314563