[ 
https://issues.apache.org/jira/browse/HDDS-17298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Siyao Meng updated HDDS-17298:
------------------------------
    Description: 
OM converts the ACLs sent with key, file, directory, multipart upload, bucket 
and volume create requests ({{KeyArgs.acls}}, {{BucketInfo.acls}}, 
{{VolumeInfo.volumeAcls}}) with {{OzoneAcl.fromProtobuf}} in 
{{validateAndUpdateCache}}. An ACL with an empty user or group name, a WORLD or 
ANONYMOUS ACL with a different name, or rights longer than 4 bytes fails there 
with {{IllegalArgumentException}} or {{AssertionError}} instead of an 
{{OMException}} with a result code.

Rights bits beyond the known ACL types are accepted by all requests that carry 
ACLs, including AddAcl, SetAcl and RemoveAcl. 
{{IAccessAuthorizer.ACLType.getACLString}} (used by {{OzoneAcl.toString}}, for 
example in audit logs) then fails with an {{ArrayIndexOutOfBoundsException}}, 
and so does {{OzoneAclStorage.fromProtobuf}} when reading such a prefix ACL 
from the prefix table. The latter also fails for a prefix ACL without any 
rights.

This change:
* adds {{OMClientRequest.toOzoneAcls}}, which converts client ACLs and throws 
{{OMException}} with {{INVALID_REQUEST}} for a malformed one, and 
{{OMClientRequest.checkAclRights}}, which does the same for rights beyond the 
known ACL types
* calls {{toOzoneAcls}} in {{preExecute}} of the create requests 
({{OMKeyRequest.resolveBucketAndCheckKeyAcls}}, {{OMBucketCreateRequest}}, 
{{OMVolumeCreateRequest}}), and {{checkAclRights}} in {{preExecute}} of the 
volume, bucket, key and prefix AddAcl, SetAcl and RemoveAcl requests
* uses {{toOzoneAcls}} in {{validateAndUpdateCache}} of the create requests, so 
a malformed ACL yields an error response there too
* makes {{ACLType.getACLString}} and {{OzoneAclStorage.fromProtobuf}} skip 
unknown rights bits, and the latter accept no rights, so existing ACLs can 
still be printed and read
* throws {{IllegalArgumentException}} instead of {{AssertionError}} in 
{{OzoneAcl.fromProtobuf}}

Compatibility:
* The Ozone client and the S3 Gateway build ACLs that already pass this 
validation, so they see no difference.
* No protocol, version or layout change.

  was:
OM converts the ACLs sent with key, file, directory, multipart upload, bucket 
and volume create requests ({{KeyArgs.acls}}, {{BucketInfo.acls}}, 
{{VolumeInfo.volumeAcls}}) with {{OzoneAcl.fromProtobuf}} in 
{{validateAndUpdateCache}}. An ACL with an empty user or group name, a WORLD or 
ANONYMOUS ACL with a different name, or rights longer than 4 bytes fails there 
with {{IllegalArgumentException}} or {{AssertionError}} instead of an 
{{OMException}} with a result code.

This change:
* validates client ACLs in {{preExecute}} of the create requests 
({{OMKeyRequest.resolveBucketAndCheckKeyAcls}}, {{OMBucketCreateRequest}}, 
{{OMVolumeCreateRequest}}) and rejects malformed ones with {{INVALID_REQUEST}}
* converts the ACLs in {{validateAndUpdateCache}} through the same helper, so a 
malformed ACL yields an error response there too
* throws {{IllegalArgumentException}} instead of {{AssertionError}} in 
{{OzoneAcl.fromProtobuf}}

Compatibility:
* The Ozone client and the S3 Gateway build ACLs that already pass this 
validation, so they see no difference.
* No protocol, version or layout change.


> Return INVALID_REQUEST for malformed ACLs in OM requests
> --------------------------------------------------------
>
>                 Key: HDDS-17298
>                 URL: https://issues.apache.org/jira/browse/HDDS-17298
>             Project: Apache Ozone
>          Issue Type: Bug
>          Components: Ozone Manager
>            Reporter: Siyao Meng
>            Assignee: Siyao Meng
>            Priority: Major
>              Labels: pull-request-available
>
> OM converts the ACLs sent with key, file, directory, multipart upload, bucket 
> and volume create requests ({{KeyArgs.acls}}, {{BucketInfo.acls}}, 
> {{VolumeInfo.volumeAcls}}) with {{OzoneAcl.fromProtobuf}} in 
> {{validateAndUpdateCache}}. An ACL with an empty user or group name, a WORLD 
> or ANONYMOUS ACL with a different name, or rights longer than 4 bytes fails 
> there with {{IllegalArgumentException}} or {{AssertionError}} instead of an 
> {{OMException}} with a result code.
> Rights bits beyond the known ACL types are accepted by all requests that 
> carry ACLs, including AddAcl, SetAcl and RemoveAcl. 
> {{IAccessAuthorizer.ACLType.getACLString}} (used by {{OzoneAcl.toString}}, 
> for example in audit logs) then fails with an 
> {{ArrayIndexOutOfBoundsException}}, and so does 
> {{OzoneAclStorage.fromProtobuf}} when reading such a prefix ACL from the 
> prefix table. The latter also fails for a prefix ACL without any rights.
> This change:
> * adds {{OMClientRequest.toOzoneAcls}}, which converts client ACLs and throws 
> {{OMException}} with {{INVALID_REQUEST}} for a malformed one, and 
> {{OMClientRequest.checkAclRights}}, which does the same for rights beyond the 
> known ACL types
> * calls {{toOzoneAcls}} in {{preExecute}} of the create requests 
> ({{OMKeyRequest.resolveBucketAndCheckKeyAcls}}, {{OMBucketCreateRequest}}, 
> {{OMVolumeCreateRequest}}), and {{checkAclRights}} in {{preExecute}} of the 
> volume, bucket, key and prefix AddAcl, SetAcl and RemoveAcl requests
> * uses {{toOzoneAcls}} in {{validateAndUpdateCache}} of the create requests, 
> so a malformed ACL yields an error response there too
> * makes {{ACLType.getACLString}} and {{OzoneAclStorage.fromProtobuf}} skip 
> unknown rights bits, and the latter accept no rights, so existing ACLs can 
> still be printed and read
> * throws {{IllegalArgumentException}} instead of {{AssertionError}} in 
> {{OzoneAcl.fromProtobuf}}
> Compatibility:
> * The Ozone client and the S3 Gateway build ACLs that already pass this 
> validation, so they see no difference.
> * No protocol, version or layout change.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to