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

Steve Loughran commented on HADOOP-15176:
-----------------------------------------

Patch 001, still WiP

Changes as noted in the description, with tests which give the assumed role 
restricted access the bucket (just some subdirs) and then attempt 
mkdir/delete/touch/rename operations underneath to see what happens. Patches 
S3A FS to not overreact if you can't create an empty directory marker because 
you don't have the permission to, even though the outcome isn't quite what a 
normal FS would deliver.

The "role model" class is in the hadoop-aws JAR tagged as unstable and for 
testing only...useful to be able to dynamically create a policy without making 
a mess of the JSON. I want it in the production JAR so that I can use it in 
some downstream testing too, seeing what other apps fail when you restrict 
access. Not because I expect people to use assumed roles in production much, 
but because the fact that you can do it in tests makes it straightforward to 
simulate restricted permissions.

Fun little thing there I'm still to try: what if you don't have s3guard write 
access & try using it in auth mode? I expect it gets inconsistent fast

> Enhance IAM assumed role support in S3A client
> ----------------------------------------------
>
>                 Key: HADOOP-15176
>                 URL: https://issues.apache.org/jira/browse/HADOOP-15176
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3, test
>    Affects Versions: 3.1.0
>         Environment: 
>            Reporter: Steve Loughran
>            Assignee: Steve Loughran
>            Priority: Major
>         Attachments: HADOOP-15176-001.patch
>
>
> Followup HADOOP-15141 with
> * Code to generate basic AWS json policies somewhat declaratively (no hand 
> coded strings)
> * Tests to simulate users with different permissions down the path of a 
> single bucket
> * test-driven changes to S3A client to handle user without full write up the 
> FS tree
> * move the new authenticator into the s3a sub-package "auth", where we can 
> put more auth stuff (that base s3a package is getting way too big)



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

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

Reply via email to