Project

General

Profile

Actions
Copy link

Bug #38638

closed

S3 policy evaluated incorrectly

Added by Davide Dal Bianco about 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
High
Assignee:
Pritha Srivastava
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
luminous mimic nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
27309
Crash signature (v1):
Crash signature (v2):

Description

Hi,

I noticed a bug when accessing Ceph via Hadoop. I am using some shared buckets with read/write access for all users. Here is the policy for the bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAll",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::<bucket>/*",
                "arn:aws:s3:::<bucket>" 
            ]
        }
    ]
}

However, if a user different from the owner (or even an anonymous user) does a GetObject/HeadObject on a non existing object, Radosgw returns status code 403 which makes the Hadoop write fail.

From the official S3 documentation:

If a requested object doesn't exist in the bucket and the requester doesn't have s3:ListBucket access, then the requester receives an HTTP 403 (Access Denied) error rather than the HTTP 404 (Not Found) error.

I tried in AWS and a bucket with the same policy returns 404, which should be the correct behaviour since ListBucket is allowed.

Related issues 3 (0 open — 3 closed)

Copied to rgw - Backport #39272: luminous: rgw: S3 policy evaluated incorrectlyResolvedActions
Copied to rgw - Backport #39273: nautilus: S3 policy evaluated incorrectlyResolvedPrashant DActions
Copied to rgw - Backport #39274: mimic: S3 policy evaluated incorrectlyResolvedNathan CutlerActions
Actions
Copy link
 #1

Updated by Brad Hubbard about 5 years ago

  • Project changed from Ceph to rgw
Actions
Copy link
 #2

Updated by Matt Benjamin about 5 years ago

  • Status changed from New to In Progress
  • Assignee set to Pritha Srivastava

pritha, could you take a look?

Matt

Actions
Copy link
 #3

Updated by Matt Benjamin about 5 years ago

  • Priority changed from Normal to High
Actions
Copy link
 #4

Updated by Pritha Srivastava about 5 years ago

This error can also be reproduced by attaching the above policy to a bucket, and then a user (not bucket owner )trying to get a non-existent object from the bucket. This happens even before the bucket policy rule is evaluated. It fails while reading permissions. (I think a non owner isn't allowed to Read permissions for the bucket). I need to dig deeper and will update when I find the reason.

Actions
Copy link
 #5

Updated by Pritha Srivastava about 5 years ago

I checked further and can see that while evaluating permissions, if the object is not found, the bucket acls are checked to see if there is any read acl set for the non owner user, and if it is not, then AccessDenied is returned. I also tried by setting a read acl on the bucket, and in that case the correct error 404 is returned. So we may need to modify code to return 404 when the object is not found, irrespective of whether a read acl is set on the bucket (for the non owner user) or not.

Actions
Copy link
 #6

Updated by Pritha Srivastava about 5 years ago

Pritha Srivastava wrote:

I checked further and can see that while evaluating permissions, if the object is not found, the bucket acls are checked to see if there is any read acl set for the non owner user, and if it is not, then AccessDenied is returned. I also tried by setting a read acl on the bucket, and in that case the correct error 404 is returned. So we may need to modify code to return 404 when the object is not found, irrespective of whether a read acl is set on the bucket (for the non owner user) or not.

On second thoughts,

RGW behaves correctly as far as acl evaluation is concerned and returns the correct error code (that is 404 when acl corresponding to ListBucket is set and 403 when that acl is not set), the correct way to solve this would be evaluate bucket policies as well after evaluating the ACLs.

Actions
Copy link
 #7

Updated by Adam Emerson about 5 years ago

We could add a special case to the permission check to return 404 if the object doesn't exist?

Actions
Copy link
 #8

Updated by Pritha Srivastava about 5 years ago

Adam Emerson wrote:

We could add a special case to the permission check to return 404 if the object doesn't exist?

Adam, this error is returned while reading the permissions while building object policies (before perm evaluation), it already has a special case for non-existent objects, where it checks for acls and if the correct acl is present on the bucket, then 404 is returned else 403 is returned (which is correct according to AWS spec). We need to evaluate bucket policies also in this place to be able to return the correct error code (may be just call the correct verify_permission method which takes both acls and bucket policies into account)

Actions
Copy link
 #10

Updated by Casey Bodley about 5 years ago

  • Status changed from In Progress to 7
  • Backport set to luminous mimic nautilus
  • Pull request ID set to 27309
Actions
Copy link
 #11

Updated by Casey Bodley about 5 years ago

  • Status changed from 7 to Pending Backport
Actions
Copy link
 #12

Updated by Nathan Cutler about 5 years ago

  • Copied to Backport #39272: luminous: rgw: S3 policy evaluated incorrectly added
Actions
Copy link
 #13

Updated by Nathan Cutler about 5 years ago

  • Copied to Backport #39273: nautilus: S3 policy evaluated incorrectly added
Actions
Copy link
 #14

Updated by Nathan Cutler about 5 years ago

Actions
Copy link
 #15

Updated by Nathan Cutler over 4 years ago

  • Status changed from Pending Backport to Resolved

While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".

Actions
Copy link

Also available in: Atom PDF