[
https://issues.apache.org/jira/browse/HDDS-14935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sammi Chen updated HDDS-14935:
------------------------------
Fix Version/s: 2.2.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> [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
> Fix For: 2.2.0
>
>
> 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]
