构建高可靠hadoop集群之4-权限指引

此文翻译自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控制。