[
https://issues.apache.org/jira/browse/HDFS-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13993676#comment-13993676
]
Chris Nauroth commented on HDFS-6326:
-------------------------------------
Earlier comments are correct that there is no concern about distcp. It only
preserves ACLs if you specify a new option, so you don't pay a cost if you're
not using ACLs. (This is actually irrelevant to the discussion of 2.4.1
anyway. The distcp -pa patch is uncommitted and currently targeting 2.5.0.)
bq. It wouldn't persist the bit in the mask, nor serialize it to ensure
complete client compatibility.
[~daryn], if I understand your proposal completely:
# {{FsPermission#fromShort}} would recognize the ACL bit and set the private
{{aclBit}} member to true. This way, the client can see an ACL bit.
# {{FsPermission#toShort}} would ignore the private {{aclBit}} member. This is
to keep values in the range 0000-01777.
# {{FsPermission#write}} would ignore the private {{aclBit}} member. This
follows from #2, since {{write}} is implemented in terms of {{toShort}}, and
once again it's done to keep visible values in the range 0000-01777.
# {{FsAclPermission}} would be a class in HDFS (not Common), and it would be
the only thing capable of serializing the ACL bit.
Am I understanding your proposal correctly? My concern with this is that it
creates a confusing API on the client side, because there isn't symmetry
between serialization and deserialization. Round-tripping an {{FsPermission}}
instance would lead to data loss.
BTW, WebHDFS responses also include the octal representation of
{{FsPermission}}. If we don't want the ACL bit visible there, then we'd need
to address that separately. This probably means a separate "aclBit" field in
the JSON response and a client-side special path to look for "aclBit" in the
JSON and then toggle it on before calling {{FsPermission#fromShort}}.
But is it really necessary to restrict the client-visible range to 0000-1777?
Is the problem theoretical or real? Do we know any real clients that are
directly referencing the {{toShort}} value? The only valid way to interpret
that data would be bitmask operations, and if any client is looking at the
proposed ACL bit today, then they are seeing undefined behavior. (IOW, the
client code is buggy.) I'd prefer not to incur a lot of code complexity
restricting the range to 0000-1777, but if there is no other choice, then I'm
willing to compromise. Let's just consider if it's really necessary.
> 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)
