[jira] [Updated] (HDDS-14935) [STS] Handle Latent Inconsistencies in S3 API Acl Checks
[ 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]
[jira] [Updated] (HDDS-14935) [STS] Handle Latent Inconsistencies in S3 API Acl Checks
[ 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]
[jira] [Updated] (HDDS-14935) [STS] Handle Latent Inconsistencies in S3 API Acl Checks
[ https://issues.apache.org/jira/browse/HDDS-14935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabian Morgan updated HDDS-14935: - Status: Patch Available (was: In Progress) > [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*. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
[jira] [Updated] (HDDS-14935) [STS] Handle Latent Inconsistencies in S3 API Acl Checks
[ 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*. 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 > 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*. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
[jira] [Updated] (HDDS-14935) [STS] Handle Latent Inconsistencies in S3 API Acl Checks
[ https://issues.apache.org/jira/browse/HDDS-14935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated HDDS-14935: -- Labels: pull-request-available (was: ) > [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. 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]
[jira] [Updated] (HDDS-14935) [STS] Handle Latent Inconsistencies in S3 API Acl Checks
[ 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]
[jira] [Updated] (HDDS-14935) [STS] Handle Latent Inconsistencies in S3 API Acl Checks
[ 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]
