You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Siyao Meng (Jira)" <ji...@apache.org> on 2021/11/11 00:26:00 UTC

[jira] [Commented] (HDDS-5891) OFS mkdir -p does not work as expected for bucket creation when volume exists due to volume create ACL check

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

Siyao Meng commented on HDDS-5891:
----------------------------------

Thanks [~zitadombi] for reporting this! As we have discussed offline, I have misunderstood the context in my earlier comment.

And thanks for your patch! It would fix the issue, but unfortunately the performance could suffer due to that extra RPC (client gets volume first, then gets bucket; rather than using ClientProtocol to get the bucket in one RPC call).

I have posted another PR https://github.com/apache/ozone/pull/2814 for review.
I have added two test cases for this change:
- One unit test for the change in behavior in {{BucketManagerImpl#getBucketInfo}} in OM, that it could throw VOLUME_NOT_FOUND now if the parent volume doesn't exist (previously it will throw BUCKET_NOT_FOUND in this case).
- The other one in an integration test class for the scenario in the jira description. To prove that a non-privileged user will be able to create a bucket with OFS mkdir -p now even though this regular user don't have volume create permission on the parent volume.

Pls take a look if you have time. Thanks! :)

> OFS mkdir -p does not work as expected for bucket creation when volume exists due to volume create ACL check
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: HDDS-5891
>                 URL: https://issues.apache.org/jira/browse/HDDS-5891
>             Project: Apache Ozone
>          Issue Type: Bug
>          Components: OFS, Ozone CLI
>            Reporter: Zita Dombi
>            Assignee: Siyao Meng
>            Priority: Major
>              Labels: pull-request-available
>
> We discovered this problem during the implementation of HttpFS Gateway. I did an acceptance test for the HttpFS with Robot framework. In the ozonesecure docker environment when I tried to make a volume with the testuser principal it didn't work, because it doesn't have permission to do it. So we decided to make a volume with an admin, set the testuser as the owner of it and then create buckets with the testuser. Even after the owner change happened successfully it gave the same error:
> User testuser/httpfs@EXAMPLE.COM doesn't have CREATE permission to access volume vol01 null null
> After debugging we found why this happened. As the bucket is not existing first it goes to the getBucket() method in the [BasicRootedOzoneClientAdapterImpl|https://github.com/apache/ozone/blob/master/hadoop-ozone/ozonefs-common/src/main/java/org/apache/hadoop/fs/ozone/BasicRootedOzoneClientAdapterImpl.java#L234] class.
> The createIfNotExist is true and both in the VOLUME_NOT_FOUND and BUCKET_NOT_FOUND cases tries to create volume first, which the testuser does not have permission. So we got the error from there, despite of the fact that testuser is the owner of that volume, so it should be able to create buckets inside.
> We were able to recreate this in terminal in the scm container (in that because it has both testuser and testuser2 as principals).
> {code:java}
> bash-4.2$ klist
> Ticket cache: FILE:/tmp/krb5cc_1000
> Default principal: testuser/scm@EXAMPLE.COM
> Valid starting     Expires            Service principal
> 10/18/21 11:23:39  10/19/21 11:23:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM
>         renew until 10/25/21 11:23:39
> {code}
> In the scm testuser is an admin, testuser/scm@EXAMPLE.COM is added as an ozone administrator in the docker-config. I did the same with testuser/httpfs@EXAMPLE.COM but it is not an admin, as the username is mapped to short user principal name (with an auth-to-local rule), which is testuser. Because of this the equality check between testuser and testuser/httpfs@EXAMPLE.COM is false, so it is not taken as an admin user.
> {code:java}
> bash-4.2$ ozone sh volume update --user=testuser2 vol02
> \{
>   "metadata" : { },
>   "name" : "vol02",
>   "admin" : "testuser",
>   "owner" : "testuser2",
>   "quotaInBytes" : -1,
>   "quotaInNamespace" : -1,
>   "usedNamespace" : 0,
>   "creationTime" : "2021-10-18T11:19:59.777Z",
>   "modificationTime" : "2021-10-18T11:24:04.183Z",
>   "acls" : [ \{
>     "type" : "USER",
>     "name" : "testuser",
>     "aclScope" : "ACCESS",
>     "aclList" : [ "ALL" ]
>   } ]
> }
> bash-4.2$ kinit -kt /opt/hadoop/compose/_keytabs/testuser2.keytab testuser2/scm@EXAMPLE.COM
> bash-4.2$ klist
> Ticket cache: FILE:/tmp/krb5cc_1000
> Default principal: testuser2/scm@EXAMPLE.COM
> Valid starting     Expires            Service principal
> 10/18/21 11:24:17  10/19/21 11:24:17  krbtgt/EXAMPLE.COM@EXAMPLE.COM
>         renew until 10/25/21 11:24:17
> bash-4.2$ ozone fs -mkdir -p ofs://om/vol01/buck01
> 2021-10-18 11:24:47,729 [main] INFO rpc.RpcClient: Creating Volume: vol01, with testuser2 as owner and space quota set to -1 bytes, counts quota set to -1
> mkdir: User testuser2/scm@EXAMPLE.COM doesn't have CREATE permission to access volume vol01 null null
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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