Ceph » rgw

When sts is enabled, LocalEngine fails to aunthenticate, but error INVALID_ACCESS_KEY gets converted to error EACESS as shown in logs below:

s3:list_buckets cache get: name=default.rgw.meta+users.keys+badauth : hit (negative entry)
2023-07-14T13:42:28.672+0530 7fd0da7946c0 5 req 13384521065249685102 0.002000010s s3:list_buckets error reading user info, uid=badauth can't authenticate
2023-07-14T13:42:28.672+0530 7fd0da7946c0 20 req 13384521065249685102 0.002000010s s3:list_buckets rgw::auth::s3::LocalEngine denied with reason=-2028
2023-07-14T13:42:28.672+0530 7fd0da7946c0 20 req 13384521065249685102 0.002000010s s3:list_buckets rgw::auth::s3::AWSAuthStrategy denied with reason=-13
2023-07-14T13:42:28.672+0530 7fd0da7946c0 5 req 13384521065249685102 0.002000010s s3:list_buckets Failed the auth strategy, reason=-13

Whereas when sts is NOT enabled, then error INVALID_ACCESS_KEY remains as is, as shown in logs below:

2023-07-14T13:55:46.339+0530 7fe93279c6c0 5 req 13980072073565935116 0.000000000s s3:list_buckets error reading user info, uid=badauth can't authenticate
2023-07-14T13:55:46.339+0530 7fe93279c6c0 20 req 13980072073565935116 0.000000000s s3:list_buckets rgw::auth::s3::LocalEngine denied with reason=-2028
2023-07-14T13:55:46.339+0530 7fe93279c6c0 20 req 13980072073565935116 0.000000000s s3:list_buckets rgw::auth::s3::AWSAuthStrategy denied with reason=-2028

Need to figure out why the conversion is happening.

So according to the design, if sts auth or any external auth is enabled, then LocalEngine serves as a 'Fallback' auth engine, and in that case the error code of the previous auth engine has to be returned. And if LocalEngine is the only available auth engine, then whatever error code it returns is returned back. This means that if any auth engine other than Local Engine is enabled, the requests need to be authenticated by the other engine, and hence the error code - which is 'Access Denied' is returned in this case. And STS Engine returns EACCES, because there is no HTTP_X_AMZ_SECURITY_TOKEN, in the incoming request.
I am not sure why the design is such that we allow requests to be successfully authenticatedby the 'Fallback' LocalEngine (even when it would have been Denied by the other engines), and in case of failures we return the error code returned by the other (sts or external) auth engine.

Currently, the auth engines return deny with EACCES that indicates that it doesnt apply, and then while evaluating the policy, we can have this special handling which checks to see if the 'reason' for failure is 'EACCES' by the previous auth engine, then the error code returned by LocalEngine will be picked up. But EACCES, is returned by some auth engines for other failure scenarios also. We could either change the default error code to something else when the engine is not applicable, or we can change the error codes in the auth engines to NOT return EACCES in any other scenario. The latter might break some tests. Which approach do you think is preferable @casey?