[
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. OMBucketAclRequest), 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*.
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. OMBucketAclRequest), 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
>
> 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. OMBucketAclRequest), 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*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
