hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6326) WebHdfs ACL compatibility is broken
Date Mon, 12 May 2014 18:39:19 GMT

    [ https://issues.apache.org/jira/browse/HDFS-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995430#comment-13995430
] 

Chris Nauroth commented on HDFS-6326:
-------------------------------------

Daryn, thank you for looking.

bq. I was going to comment on the lack of bitwise and after the shift.  :-)

Darn, there is no hiding my shame.  :-)

bq. Bits 10 & 11 are for set-uid/gid so we should probably use bit 12 to be safe.

Yes, we can use bit 12.

bq. Since the acl bit is intended to be invisible to the client, shouldn't it be ignored in
{{FSPermission#equals}}?

OK, let's do that.  I'll re-raise my concern that this whole business of hiding the bit causes
confusion in the client-side API.  Now, we'll have a situation where 2 instances can appear
equal even though one has the ACL bit and the other doesn't.  I suppose it's best that we're
at least consistent in ignoring it, so let's remove it from {{equals}}.

bq. Same for {{FsPermission#toString}}, should probably be left to {{FsShell}} or others to
add the "+".

Yes, same as above.

bq. In {{AclCommands#processPath}}, is it guaranteed (probably yes?) that the owner/group/etc
will be identical in the acl vs. file status?

Yes, this is guaranteed, barring race conditions involving a concurrent process running chown
interleaved between the {{getFileInfo}} and the {{getAclStatus}} RPCs.

bq. Should we avoid changing {{PBHelper. convert(FsPermission)}} and just let {{FsAclPermission#toShort}}
serialize the bit?

Yes, we can do that.

bq. 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?

This change is required so that the shell (and others) can get a {{true}} return from {{FsPermission#getAclBit}}
via the {{FsAclPermission}} subclass.  The patch is hiding the bit from the 16-bit representation
seen by callers of {{FsPermission#toShort}}, but we need to preserve the information somehow.
 The PB conversion layer seems to be the only remaining choice, but let me know if you had
another idea in mind.

> 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)

Mime
View raw message