在hadoop中，我启用了授权。我为一个目录设置了几个acl。
当我在hadoop bin中执行getfacl命令时，我可以看到其中的掩码值。
hadoop fs -getfacl /Kumar
# file: /Kumar
# owner: Kumar
# group: Hadoop
user::rwx
user:Babu:rwx
group::r-x
mask::rwx
other::r-x如果我使用webhdfs运行相同的命令，则不显示掩码值。
http://localhost:50070/webhdfs/v1/Kumar?op=GETACLSTATUS
{
"AclStatus": {
"entries": [
"user:Babu:rwx",
"group::r-x"
],
"group": "Hadoop",
"owner": "Kumar",
"permission": "775",
"stickyBit": false
}
}为什么不在getfacl命令的webhdfs中显示掩码值。
帮我弄清楚。
1条答案
按热度按时间laximzn51#
hdfs实现posix acl模型。链接的文档解释了掩码条目被持久化到经典posix权限模型的组权限位中。这样做是为了支持posix acl的需求，并且还支持与chmod等现有工具的向后兼容性，这些工具不知道扩展的acl条目。引用该文件：
在最小ACL中，组类权限与拥有的组权限相同。在扩展ACL中，group类可能包含其他用户或组的条目。这会导致一个问题：这些附加条目中的某些条目可能包含所有者组条目中不包含的权限，因此所有者组条目权限可能与组类权限不同。
此问题通过掩码条目解决。使用最少的ACL，组类权限Map到拥有的组条目权限。对于扩展ACL，组类权限Map到掩码条目权限，而拥有的组条目仍然定义拥有的组权限。
...
当应用程序更改任何所有者、组或其他类权限（例如，通过chmod命令）时，相应的acl条目也会更改。同样，当应用程序更改Map到某个用户类的acl条目的权限时，该类的权限也会更改。
这与您的问题有关，因为这意味着掩码实际上并没有作为扩展acl条目持久化。相反，它在权限位中。在查询webhdfs时，您进行了一个“原始”api调用来检索有关acl的信息。运行时
getfacl，您已经运行了一个应用程序，该应用程序在该api调用之上分层附加的显示逻辑。getfacl注意，对于具有acl的文件，组权限位被解释为掩码，因此它相应地显示。这并不是webhdfs特有的。如果应用程序要调用
getAclStatus通过namenode的rpc协议，它将看到webhdfs响应的等价物。另外，如果你用getfacl命令webhdfs://uri，则命令仍将显示掩码，因为应用程序知道应用该逻辑，而不管文件系统实现如何。