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

chaosxin

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

OperationOwnershipParentAncestorFinalSub-treeappendNON/AN/AWRITEN/AconcatNO [2]WRITE (sources)N/AREAD (sources), WRITE (destination)N/AcreateNON/AWRITEWRITE [1]N/AcreateSnapshotYESN/AN/AN/AN/AdeleteNO [2]WRITEN/AN/AREAD, WRITE, EXECUTEdeleteSnapshotYESN/AN/AN/AN/AgetAclStatusNON/AN/AN/AN/AgetBlockLocationsNON/AN/AREADN/AgetContentSummaryNON/AN/AN/AREAD, EXECUTEgetFileInfoNON/AN/AN/AN/AgetFileLinkInfoNON/AN/AN/AN/AgetLinkTargetNON/AN/AN/AN/AgetListingNON/AN/AREAD, EXECUTEN/AgetSnapshotDiffReportNON/AN/AREADREADgetStoragePolicyNON/AN/AREADN/AgetXAttrsNON/AN/AREADN/AlistXAttrsNOEXECUTEN/AN/AN/AmkdirsNON/AWRITEN/AN/AmodifyAclEntriesYESN/AN/AN/AN/AremoveAclYESN/AN/AN/AN/AremoveAclEntriesYESN/AN/AN/AN/AremoveDefaultAclYESN/AN/AN/AN/AremoveXAttrNO [2]N/AN/AWRITEN/ArenameNO [2]WRITE (source)WRITE (destination)N/AN/ArenameSnapshotYESN/AN/AN/AN/AsetAclYESN/AN/AN/AN/AsetOwnerYES [3]N/AN/AN/AN/AsetPermissionYESN/AN/AN/AN/AsetReplicationNON/AN/AWRITEN/AsetStoragePolicyNON/AN/AWRITEN/AsetTimesNON/AN/AWRITEN/AsetXAttrNO [2]N/AN/AWRITEN/AtruncateNON/AN/AWRITEN/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控制。