PutObjectRetention: policy conditions read the request header, the handler applies the request body

Summary

For a standalone PutObjectRetention request, the policy engine evaluates s3:object-lock-retain-until-date and s3:object-lock-mode from the x-amz-object-lock-* request headers. The handler then applies the mode and date from the XML request body. Nothing compares the two. A principal whose policy allows s3:PutObjectRetention only under a date condition can send a header that satisfies the condition and a body that does not, and the handler applies the body. In COMPLIANCE mode nobody can shorten or remove the resulting lock before the chosen date, the operator included.

Details

Line numbers below are from tag 1.0.0, where we measured it. Tag 1.0.1 and main at db2abcf0, checked on 2026-10-07, have the same logic at shifted lines.

• rustfs/src/auth.rs fills the object-lock condition keys object-lock-retain-until-date, object-lock-mode and object-lock-legal-hold only from the x-amz-object-lock-* request headers, lines 729-743.
• authorization_conditions in rustfs/src/storage/access.rs, line 827, builds the condition map from req.headers and req.uri.query() only. Its merge helpers add list-bucket query values and x-amz-tagging. Nothing adds values from a request body.
• put_object_retention in the same file, line 3209, authorizes PutObjectRetentionAction with those conditions. It never consults req.input.retention for the policy decision, and then it applies req.input.retention.

AWS documents `s3:object-lock-retain-…