You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Fabian Morgan (Jira)" <ji...@apache.org> on 2026/04/27 15:44:00 UTC
[jira] [Closed] (HDDS-14804) [STS] Part 3 - IAM Session Policy and List Bucket Improvements
[ https://issues.apache.org/jira/browse/HDDS-14804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabian Morgan closed HDDS-14804.
--------------------------------
> [STS] Part 3 - IAM Session Policy and List Bucket Improvements
> --------------------------------------------------------------
>
> Key: HDDS-14804
> URL: https://issues.apache.org/jira/browse/HDDS-14804
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Fabian Morgan
> Assignee: Fabian Morgan
> Priority: Major
> Labels: pull-request-available
>
> We need to be able to tell whether an S3 STS call is authorized for listing files in a bucket only vs being able to download a file, because those are different actions in S3 (ListBucket vs GetObject). To differentiate, use *LIST* at key/object level for listing permission and use *READ* at key/object level for downloading permission. Currently, the *OmMetadataReader* authorizes only *READ* at key level for the listing operations. In order to not break existing functionality, have STS-specific checks that authorize against *LIST* permission instead. Further, because of how shallow listing works, in some cases (ex. root listing with a delimiter), it loses the context of what the original prefix was on the S3 request. For STS authorization, we need this original prefix, so introduce an optional listPrefix in the protocol to support this.
> Here are a quick summary of the total requisite changes:
> 1. Support passing list prefix on root listing so STS can authorize against it.
> 2. Filter out non-ListBucket actions (ex GetObject, PutObject, ListBucketMultipartUploads, etc) when Conditions are present since we only support s3:prefix Condition and s3:prefix is only applicable for ListBucket and ListBucketVersions (we don't support this).
> 3. Keep track of the operator (i.e. StringEquals or StringLike) when using conditions. If the operator is StringEquals and a wildcard (* or ?) is used, ignore that condition since Ranger can’t authorize against literal asterisk or question mark.
> 4. Change ListBucket to validate LIST permission on the object instead of READ so we can determine if we should allow listing the object or downloading the object (READ would be for downloading).
> This part 3 is to change the IAM Session Policy Resolver to validate LIST permission on the key for ListBucket action instead of READ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org