[
https://issues.apache.org/jira/browse/HDFS-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995256#comment-13995256
]
Daryn Sharp commented on HDFS-6326:
-----------------------------------
I was going to comment on the lack of bitwise and after the shift. :)
Other comments/questions:
* Bits 10 & 11 are for set-uid/gid so we should probably use bit 12 to be safe.
* Since the acl bit is intended to be invisible to the client, shouldn't it be
ignored in {{FSPermission#equals}}?
* Same for {{FsPermission#toString}}, should probably be left to FsShell or
others to add the "+".
* In {{AclCommands#processPath}}, is it guaranteed (probably yes?) that the
owner/group/etc will be identical in the acl vs. file status? If no, maybe the
first line should be changed to call getAclStatus if the bit is set, and most
of the subsequent code left alone?
* Should we avoid changing {{PBHelper. convert(FsPermission)}} and just let
{{FsAclPermission#toShort}} serialize the bit?
* Does {{PBHelper.convert(FsPermissionProto)}} need to be changed? Assuming
it's only used to decode incoming permissions in a rpc call where we don't care
about the bit?
> WebHdfs ACL compatibility is broken
> -----------------------------------
>
> Key: HDFS-6326
> URL: https://issues.apache.org/jira/browse/HDFS-6326
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Affects Versions: 3.0.0, 2.4.0
> Reporter: Daryn Sharp
> Assignee: Chris Nauroth
> Priority: Blocker
> Attachments: HDFS-6326.1.patch, HDFS-6326.2.patch, HDFS-6326.3.patch
>
>
> 2.4 ACL support is completely incompatible with <2.4 webhdfs servers. The NN
> throws an {{IllegalArgumentException}} exception.
> {code}
> hadoop fs -ls webhdfs://nn/
> Found 21 items
> ls: Invalid value for webhdfs parameter "op": No enum constant
> org.apache.hadoop.hdfs.web.resources.GetOpParam.Op.GETACLSTATUS
> [... 20 more times...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
