Project

General

Profile

Actions

Bug #52302

closed

assumed-role: s3api head-object returns 403 Forbidden, even if role has ListBucket, for non-existent object, patch in https://tracker.ceph.com/issues/49780 inconsistent with AWS

Added by Chris Durham over 2 years ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Target version:
-
% Done:

100%

Source:
Community (user)
Tags:
sts role backport_processed
Backport:
octopus pacific
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

The solution to an assumed role returning 404 instead of 403 for a non existent object, as detailed in https://tracker.ceph.com/issues/49780 , is inconsistent with the same issue in AWS.

I am using octopus 15.2.14 on CentOS 8

In https://tracker.ceph.com/issues/49780 the solution implies that the role policy requires a 'Principal' Key: (which does work in ceph):

However, in real AWS, the '"Principal": "*"' is not required to get a 404 for a non-existent object. Without the 'Principal' key in ceph, we still get a 403 on ceph for a non-existent object.

I understand that the Principal key may limit who in the role can access the buckets, but the fix should be consistent with the way AWS does it, with the Principal key (presumably) optional.

See comments on https://tracker.ceph.com/issues/49780 for details


Related issues 2 (0 open2 closed)

Copied to rgw - Backport #53647: octopus: assumed-role: s3api head-object returns 403 Forbidden, even if role has ListBucket, for non-existent object, patch in https://tracker.ceph.com/issues/49780 inconsistent with AWSRejectedActions
Copied to rgw - Backport #53648: pacific: assumed-role: s3api head-object returns 403 Forbidden, even if role has ListBucket, for non-existent object, patch in https://tracker.ceph.com/issues/49780 inconsistent with AWSResolvedPritha SrivastavaActions
Actions

Also available in: Atom PDF