Project

General

Profile

Bug #42803

Authentication failure at radosgw for presigned urls

Added by Biswajeet Patra 5 months ago. Updated about 2 months ago.

Status:
Triaged
Priority:
Normal
Assignee:
-
Target version:
-
% Done:

0%

Source:
Tags:
s3 v2auth
Backport:
nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature:

Description

We recently faced an issue with radosgw authentication of presigned urls. The presigned url generated by client to download object fails at radosgw with http error 403 i.e SignatureDoesNotMatch.

The radosgw computes the signature (v2 signature in this case) using the s3 specification https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html. In this process, a string_to_sign is created by concatenating selected elements from requests which is then authenticated using hmac to create the final signature. If this signature matches with the client signature, the authentication is successful or else it fails with SignatureDoesNotMatch error. As part of the StringToSign, the CanonicalizedAmzHeaders should only include headers that start with "x-amz-" and ignore other headers. But in the radosgw code, there are other meta prefixes that are checked against the http request headers and if matched are included in the CanonicalizedAmzHeaders to compute the final signature. For e.g, if a request header contains "HTTP_X_ACCOUNT" its selected by radosgw to include in amz_headers but the same will be ignored by AWS SDK as it does not start with "x-amz-". This will result in different signature computed by client and radosgw.

Code Snippet: rgw_common.cc
struct str_len meta_prefixes[] = { STR_LEN_ENTRY("HTTP_X_AMZ"),
STR_LEN_ENTRY("HTTP_X_GOOG"),
STR_LEN_ENTRY("HTTP_X_DHO"),
STR_LEN_ENTRY("HTTP_X_RGW"),
STR_LEN_ENTRY("HTTP_X_OBJECT"),
STR_LEN_ENTRY("HTTP_X_CONTAINER"),
STR_LEN_ENTRY("HTTP_X_ACCOUNT"), {NULL, 0} };

The method init_meta_info() which matches the above prefixes is called from RGWREST::preprocess() which is invoked for all s3 requests. It will be helpful to know as to why these prefixes that are not specified by AWS S3 comes in the path of s3 authentication. Was it added for swift use-cases only? If so, then why its included in rgw_common.cc?
As a proposed fix, we can remove the highlighted meta prefixes that are not specified by aws from the s3 authentication path signature calculation. Let me know if you have any queries or solutions.

History

#1 Updated by Casey Bodley 5 months ago

  • Status changed from New to 12
  • Tags set to s3 v2auth
  • Backport set to nautilus

#2 Updated by Patrick Donnelly 4 months ago

  • Status changed from 12 to New

#3 Updated by Casey Bodley 3 months ago

We discussed this issue and you proposed a fix. Any updates on this work?

#4 Updated by Casey Bodley about 2 months ago

  • Status changed from New to Triaged

#5 Updated by Or Friedmann about 2 months ago

I will take a loot at it

Also available in: Atom PDF