[
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
* skips both of the above when {{ozone.om.object.creation.ignore.client.acls}}
is true, so the create requests ignore the client ACLs without validating them
* 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.
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.
> 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
> * skips both of the above when
> {{ozone.om.object.creation.ignore.client.acls}} is true, so the create
> requests ignore the client ACLs without validating them
> * 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]
