[
https://issues.apache.org/jira/browse/HDDS-14935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabian Morgan updated HDDS-14935:
---------------------------------
Description:
Currently, S3 APIs are not consistent in how ACL checks are applied. For
example, *PutObject* (i.e. OMKeyCreateRequest, OMAllocateBlockRequest,
OMKeyCommitRequest), *DeleteObject* (i.e. OMKeyDeleteRequest),
*PutObjectTagging* (i.e. S3PutObjectTaggingRequest), etc. perform their ACL
checks in *preExecute()* which is on the OM leader RPC thread.
However, APIs like *DeleteBucket* (i.e. OMBucketDeleteRequest), *PutBucketAcl*
(i.e. OMBucketSetAclRequest), etc. perform their ACL checks in
*validateAndUpdateCache()* which is on the Ratis apply thread. This affects
STS in that the STSTokenIdentifier ThreadLocal currently is not available on
the Ratis apply thread, so if the STS token has an inline session policy, some
ACL checks that should pass would fail. This ticket addresses the
inconsistency by ensuring the ThreadLocal is always available on the Ratis
apply thread via updates to *OzoneManagerStateMachine*.
A separate PR is already open to move the checks to the correct place
(https://github.com/apache/ozone/pull/9653 and
https://issues.apache.org/jira/browse/HDDS-13855), but this ticket is a
fallback in case any future API has the check in the incorrect place, so it
won't break STS.
was:
Currently, S3 APIs are not consistent in how ACL checks are applied. For
example, *PutObject* (i.e. OMKeyCreateRequest, OMAllocateBlockRequest,
OMKeyCommitRequest), *DeleteObject* (i.e. OMKeyDeleteRequest),
*PutObjectTagging* (i.e. S3PutObjectTaggingRequest), etc. perform their ACL
checks in *preExecute()* which is on the OM leader RPC thread.
However, APIs like *DeleteBucket* (i.e. OMBucketDeleteRequest), *PutBucketAcl*
(i.e. OMBucketSetAclRequest), etc. perform their ACL checks in
*validateAndUpdateCache()* which is on the Ratis apply thread. This affects
STS in that the STSTokenIdentifier ThreadLocal currently is not available on
the Ratis apply thread, so if the STS token has an inline session policy, some
ACL checks that should pass would fail. This ticket addresses the
inconsistency by ensuring the ThreadLocal is always available on the Ratis
apply thread via updates to *OzoneManagerStateMachine*.
> [STS] Handle Latent Inconsistencies in S3 API Acl Checks
> --------------------------------------------------------
>
> Key: HDDS-14935
> URL: https://issues.apache.org/jira/browse/HDDS-14935
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Fabian Morgan
> Assignee: Fabian Morgan
> Priority: Major
> Labels: pull-request-available
>
> Currently, S3 APIs are not consistent in how ACL checks are applied. For
> example, *PutObject* (i.e. OMKeyCreateRequest, OMAllocateBlockRequest,
> OMKeyCommitRequest), *DeleteObject* (i.e. OMKeyDeleteRequest),
> *PutObjectTagging* (i.e. S3PutObjectTaggingRequest), etc. perform their ACL
> checks in *preExecute()* which is on the OM leader RPC thread.
> However, APIs like *DeleteBucket* (i.e. OMBucketDeleteRequest),
> *PutBucketAcl* (i.e. OMBucketSetAclRequest), etc. perform their ACL checks in
> *validateAndUpdateCache()* which is on the Ratis apply thread. This affects
> STS in that the STSTokenIdentifier ThreadLocal currently is not available on
> the Ratis apply thread, so if the STS token has an inline session policy,
> some ACL checks that should pass would fail. This ticket addresses the
> inconsistency by ensuring the ThreadLocal is always available on the Ratis
> apply thread via updates to *OzoneManagerStateMachine*.
> A separate PR is already open to move the checks to the correct place
> (https://github.com/apache/ozone/pull/9653 and
> https://issues.apache.org/jira/browse/HDDS-13855), but this ticket is a
> fallback in case any future API has the check in the incorrect place, so it
> won't break STS.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
