[
https://issues.apache.org/jira/browse/HDFS-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13991262#comment-13991262
]
Haohui Mai commented on HDFS-6326:
----------------------------------
Just copy past from my previous comments in HDFS-5923:
{quote}
The v0 patch takes a more aggressive approach, which removes the ACL bit
completely. The rationale is the following:
Some applications might assume that FsPermission stay within the range of
0~0777. Changing FsPermission might lead to unexpected issues.
There are not many users care about whether the file has ACL except for ls.
Since ls is not in the critical path, ls can make a separate getAclStatus()
call to calculate the ACL bit.
{quote}
The user shouldn't care about whether the file has ACL in most cases, since the
server side enforces the ACL. The only two meaningful exception that I can
think of right now are (1) to perform ls, and (2) to do {{distcp -p}}.
Note that in the second case but it requires calling {{getAclStatus()}}
explicitly anyway. Given the issues that Chris has pointed out, I still think
that it might be worthwhile to put down some hacks in ls to make it work (since
{{ls}} is not on the critical path). Any thoughts?
> 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
>
>
> 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)
