Bug #42803
openAuthentication failure at radosgw for presigned urls
0%
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.
Updated by Casey Bodley over 4 years ago
- Status changed from New to 12
- Tags set to s3 v2auth
- Backport set to nautilus
Updated by Casey Bodley over 4 years ago
We discussed this issue and you proposed a fix. Any updates on this work?