hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Fabbri (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-15525) s3a: clarify / improve support for mixed ACL buckets
Date Sat, 09 Jun 2018 00:12:00 GMT

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

Aaron Fabbri commented on HADOOP-15525:
---------------------------------------

Actually, refreshing my memory here, [~stevel@apache.org] has already done most of this--though
I'm proposing a more restrictive example.

The test case {{org.apache.hadoop.fs.s3a.auth.ITestAssumeRole#testRestrictedWriteSubdir}}
([link|https://github.com/apache/hadoop/blob/fba1c42adc1c8ae57951e1865ec2ab05c8707bdf/hadoop-tools/hadoop-aws/src/test/java/org/apache/hadoop/fs/s3a/auth/ITestAssumeRole.java#L389])
is a good example.

I'm wondering if adding explicit create and delete permissions on parent directory keys (e.g.
allow deleteObject on "/a/" "/a/b/" "/a/b/c/") would avoid the "cannot update directory markers"
problem. Since there is no wildcard after these keys, they should only grant access to manipulating
the actual empty directory markers, right?

Will try to play around with that when I get back from break.

> s3a: clarify / improve support for mixed ACL buckets
> ----------------------------------------------------
>
>                 Key: HADOOP-15525
>                 URL: https://issues.apache.org/jira/browse/HADOOP-15525
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: fs/s3
>    Affects Versions: 3.0.0
>            Reporter: Aaron Fabbri
>            Assignee: Aaron Fabbri
>            Priority: Major
>
> Scenario: customer wants to only give a Hadoop cluster access to a subtree of an S3
bucket.
> For example, assume Hadoop uses some IAM identity "hadoop", which they wish to grant
full permission to everything under the following path:
> s3a://bucket/a/b/c/hadoop-dir
> they don't want hadoop user to be able to read/list/delete anything outside of the hadoop-dir
"subdir"
> Problems: 
> To implement the "directory structure on flat key space" emulation logic we use to present
a Hadoop FS on top of a blob store, we need to create / delete / list ancestors of {{hadoop-dir}}.
(to maintain the invariants (1) zero-byte object with key ending in '/' exists iff empty directory
is there and (2) files cannot live beneath files, only directories.)
> I'd like us to (1) document a an example with IAM ACLs policies that gets this basic
functionality, and consider (2) making improvements to make this easier.
> We've discussed some of these issues before but I didn't see a dedicated JIRA.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message