此文翻译自 http://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html
译注：实际部署中，没有安全控制的hadoop的，最好不要使用，因为可能很多心血会毁于一旦。
概览
HDFS实现了文件和目录的权限模型，这个模式实现了POSIX的许多内容。每个文件或者目录都和一个用户和组关联。对属主，组中其它用户，和其它用户具有分开的权限。文件需要r/w用于读和写。目录使用r/w来列出文件目录/创建删除文件（或者目录），x则是用于访问子目录。
相对于POSIX，HDFS文件没有setuid和setgid,文件也没有可执行的概念，目录也是如此。有关标记位可以设置在目录上，阻止超级用户外的用户，目录的属主或者文件属主，删除或者移动目录内的文件。为文件设置标记位是没有效果的。HDFS为文件目录设置权限。习惯上，unix用于表达和显示的模式还是会被采用，包括使用8进制值的表述。
当一个文件或者目录创建的时候，客户进程的用户识别是文件或者目录的属主，文件或者目录的组是它上级目录的组（BSD规则）。
译注：SETUID和SETGID是posix系统中重要的两个函数，都和文件权限有关，分别是做用户ID和组ID的匹配，如果匹配，则有关的进程就会具有相关的权限。
HDFS也实现了POSIX acls的部分（ACLS-ACCESS CONTROL LISTS-存取控制列表），这样可以提供更好的权限粒度。后文会更详细讨论acls.
每个存取hdfs文件的客户进程都有两部分识别-包括用户名称和组列表。无论什么时候，当客户端进程要访问文件或者目录的时候，HDFS都会执行权限检查(假定客户进程访问的是名称为foo的文件或者目录)。
- 如果用户和foo的属主匹配，那么通过测试
- 或者foo的组匹配组列表中的某个，那么也通过测试
- 否则，测试foo的其它权限
如果权限检查失败，进程也就失败了。
用户标识
从hadoop 0.22开始，hadoop支持两种不同的模式，用于确定用户的标识，模式通过hadoop.security.authentication来设定：
-
simple--简单
这种模式下，客户进程的标识由主机操作系统来确定。在类unix系统中，用户名称等同于'whoami'的结果。译注：就是客户进程在主机上执行whoami获得结果
-
kerberos
这种模式下（身份识别），客户进程的识别通过kerberos证书来确认。例如,用户可能会使用kinit工具来获得一个kerberos tgt，并利用klist来确认它们当前的委托。当kerberos委托和hdfs的用户匹配的时候，只会取主要的内容。例如，委托todd/foobar@CORP.COMPANY.COM会扮演HDFS中用户todd的角色。
如果不考虑以上模式，那么身份识别机制并非hdfs固有的。HDFS内部并不考虑创建用户标识，建立组，或者处理用户证书。
译注：原文的意思是，用户认证这东西，并非HDFS固有，HDFS不需要这个也可以好好工作，因为0.22前并不支持这个。
组映射
一旦一个用户已经如前确定，组清单就通过组映射来确定，这个服务通过属性hadoop.security.group.mapping设定。具体细节参与hadoop组映射。
译注：如果不想搞得太复杂，也可以使用默认的组映射(基于jni和操作系统shell).
权限检查
每个HDFS操作都要求用户具有特定的权限，这些权限通过归属，组归属或者其它权限授予。一个操作可能需要在一个个路径的多个部分执行权限检查，而不仅仅是最后的部分。此外，一些操作依赖于对路径属主的检查。
所有的操作要求遍历存取。遍历存取要求路径中所有部件上具有执行（EXECUTE)权限,除了最后一个部分。例如，任何存取/foo/bar/baz的操作，调用程序都必须对/,/foo,/foo/bar具有执行权限。
下表描述了HDFS对路径中每个部分所执行的权限检查：
- Ownership: 如果调用者是路径属主，是否要做检查。典型地，修改属主或者权限元数据的时候，要求调用者必须是属主。
- Parent: 被请求路径的上级目录。例如目录/foo/bar/baz的上级目录是/foo/bar.
- Ancestor: 祖先- 例如路径/foo/bar/baz的祖先是/foo/bar如果后者存在。如果/foo/bar不存在，而/foo存在，那么祖先就是/foor.(译注：这有点难于理解，难道中间一个目录不存在，就可以有3级目录？)
- Final: 例如，如果请求路径/foo/bar/baz,那么/foo/bar/baz就是最后一个。
- Sub-tree: 子树。如果被请求的路径是目录，那么目录和所有的遍历子目录构成子树。例如，对于目录/foo/bar/baz ,有两个子树，分别是/foo/bar/baz,/foo/bar/baz/buz和/boo/bar/baz/boo
| Operation | Ownership | Parent | Ancestor | Final | Sub-tree |
|---|---|---|---|---|---|
| append | NO | N/A | N/A | WRITE | N/A |
| concat | NO [2] | WRITE (sources) | N/A | READ (sources), WRITE (destination) | N/A |
| create | NO | N/A | WRITE | WRITE [1] | N/A |
| createSnapshot | YES | N/A | N/A | N/A | N/A |
| delete | NO [2] | WRITE | N/A | N/A | READ, WRITE, EXECUTE |
| deleteSnapshot | YES | N/A | N/A | N/A | N/A |
| getAclStatus | NO | N/A | N/A | N/A | N/A |
| getBlockLocations | NO | N/A | N/A | READ | N/A |
| getContentSummary | NO | N/A | N/A | N/A | READ, EXECUTE |
| getFileInfo | NO | N/A | N/A | N/A | N/A |
| getFileLinkInfo | NO | N/A | N/A | N/A | N/A |
| getLinkTarget | NO | N/A | N/A | N/A | N/A |
| getListing | NO | N/A | N/A | READ, EXECUTE | N/A |
| getSnapshotDiffReport | NO | N/A | N/A | READ | READ |
| getStoragePolicy | NO | N/A | N/A | READ | N/A |
| getXAttrs | NO | N/A | N/A | READ | N/A |
| listXAttrs | NO | EXECUTE | N/A | N/A | N/A |
| mkdirs | NO | N/A | WRITE | N/A | N/A |
| modifyAclEntries | YES | N/A | N/A | N/A | N/A |
| removeAcl | YES | N/A | N/A | N/A | N/A |
| removeAclEntries | YES | N/A | N/A | N/A | N/A |
| removeDefaultAcl | YES | N/A | N/A | N/A | N/A |
| removeXAttr | NO [2] | N/A | N/A | WRITE | N/A |
| rename | NO [2] | WRITE (source) | WRITE (destination) | N/A | N/A |
| renameSnapshot | YES | N/A | N/A | N/A | N/A |
| setAcl | YES | N/A | N/A | N/A | N/A |
| setOwner | YES [3] | N/A | N/A | N/A | N/A |
| setPermission | YES | N/A | N/A | N/A | N/A |
| setReplication | NO | N/A | N/A | WRITE | N/A |
| setStoragePolicy | NO | N/A | N/A | WRITE | N/A |
| setTimes | NO | N/A | N/A | WRITE | N/A |
| setXAttr | NO [2] | N/A | N/A | WRITE | N/A |
| truncate | NO | N/A | N/A | WRITE | N/A |
[1] 在create的时候，如果启用覆盖(overwrite)选项，且路径中已经有文件，那么对最终目录的write权限是唯一要求的权限。
[2] 任何检查上级目录权限的操作，也会检查上级目录的归属，如果上级目录有设置权限。
[3] 调用 setOwner来修改文件的属主，要求有HDFS操作用户权限。HDFS的超级用户存取并不要求修改组，但调用者必须是文件的属主，并且是特定组的成员。
译注：对操作的权限，以上表为准，读者只要关心上表即可，原文的有些内容翻译无法到位。
理解实现
对文件和目录的每个操作都需要传递全路径给名称节点，每个操作都需要进行权限检查。
客户端框架会隐式关联用户标识，然后连接到名称节点，以此减少对现有客户端api的变更需求。
有时候，在某个文件上的操作成功了，但重新做的时候，确失败了，因为文件或者目录可能不存在了。例如，当客户端第一次读取一个文件，它会向名称节点请求找到文件的第一个数据块。但请求第二个块的时候可能失败。另一方面，删除一个文件并不会被取消其它客户端对这个文件的访问（早知道这文件的的块)(译注：原文有点晦涩，应该的意思是如果有个客户端正在访问一个文件，而另外一个操作时删除文件，那么删除操作并不会取消前面的读取操作）。
考虑到权限，一个客户端对文件的存取可能中途被撤销。
此外，如果一个客户端正在存取文件的时候，修改文件的权限不会影响现有的存取操作。
文件系统API的变更
译注：由于不想关心老的版本，本处对于原文的翻译略。
原文的大意是添加了几个新的方法：
- 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的限制（译注umask是linux的一个环境变量，顾名思义就是用户掩码，是用于设置目录文件的权限，可能是屏蔽也可能是赋予，需要看情形）。
应用shell变更
新操作
-
chmod [-R] mode file ...
只有文件属主或者超级用户才可以修改文件的mod(权限）。
-
chgrp [-R] group file ...
用户必须是文件的属主且属于特定的组，或者用户必须是超级用户。
-
chown [-R] [owner][:[group]] file ...
只有超级用户才可以修改文件属主。
-
ls file ...
-
lsr file ... 译注：这个文件执行的时候，反而会一直提示使用 -ls -r
超级用户
所谓的超级用户，就是执行名称节点进程的用户。或者说，谁启动名称节点，谁就是超级用户。超级用户可以做任何事情，权限检查永远是成功的。HDFS的超级用户不必是名称节点主机上的操作系统超级用户 ，集群中其它节点不是一定要有这个用户。
此外，管理员可能会使用配置的参数来标识一个组，如果设置了，那么组成员也是超级用户。
web服务器
默认情况下，web服务器的标识是可配参数。这就是说，名称节点并不关注真正的用户，但web服务器确会表现的 好像有识别一样，除非指定的标识匹配超级用户，否则部分名称空间可能无法通过web服务器存取。
ACLs
除了传统的posix权限模式，hdfs也支持posix acl.
默认情况下，不支持acls，名称节点不允许创建acls.为了启用这个，可以把名称节点的dfs.namenode.acls.enabled 设置为true。
一个acl包含了多个acl条目。每个acl条目设定了用户或者用户组的权限。例如：
user::rw-
user:bruce:rwx #effective:r--
group::r-x #effective:r--
group:sales:rwx #effective:r--
mask::r--
other::r--
每个条目由三个部分构成：类型，名称（可选），权限
每个acl都必须有一个mask(掩码),如果没有提供，那么会通过计算所有条目的权限的和(and操作）来获得一个mask,并把这个mask插入。
在具有acl的文件行执行chmod，实际上是修改mask的权限。因为mask是用作过滤器的，这有效限制了所有扩展acl条目的权限，而不仅仅是修改组条目（那样可能会忘记处理其它扩展条目）。
“access ACL"和”default ACL"之间的模式也有差异，前者定义了权限检查的规则，后者定义了下级文件目录创建的时候所获得默认ACL.
只有目录有"default ACL".
译注：由于hdfs的acl和linux的极其类似，所以不再翻译一些重复的内容。hdfs目录把自己整得和普通文件系统一样，但它们之间还是有很大的不同的。
ACls 文件系统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;
ACL shell命令
-
hdfs dfs -getfacl [-R] <path>
显示文件或者目录的acl
-
hdfs dfs -setfacl [-R] [-b |-k -m |-x <acl_spec> <path>] |[--set <acl_spec> <path>]
设置acl
-
hdfs dfs -ls <args>
如果文件或者目录具有acl,那么权限串的右边会有+号。
配置参数
-
dfs.permissions.enabled = true
启用权限检查。但chmod, chgrp, chown and setfacl总是检查，无论是否开启。
-
dfs.web.ugi = webuser,webgroup
web服务器的用户和组。如果有多个组，请以逗号分隔。
-
dfs.permissions.superusergroup = supergroup
超级用户组
-
fs.permissions.umask-mode = 0022
创建文件和目录时候所使用umask值。在控制文件中，也可以使用18（10进制，umask字符串通常用8进制表示).
-
dfs.cluster.administrators = ACL-for-admins
集群管理员。主要用于访问默认的servlet.
-
dfs.namenode.acls.enabled = true
启用hdfs的acl控制。