mirror of
https://github.com/versity/versitygw.git
synced 2026-10-22 06:12:39 +00:00
niksis02
834ce25e0b
Some requests need more than one S3 action authorized on the same object. `PutObject`, `CopyObject` and `CreateMultipartUpload` add `s3:PutObjectTagging`, `s3:PutObjectLegalHold` or `s3:PutObjectRetention` depending on the headers sent, and a browser-based `POST` with a `tagging` field adds `s3:PutObjectTagging`. The gateway allowed such a request only when a single policy source allowed every action, because `verifyBucketPolicy` and `aggregateActionDecisions` each reduced their side to one verdict before `objectsAccessErrors` combined them. S3 authorizes each action separately. As a result, a user granted `s3:PutObject` by the bucket policy and `s3:PutObjectTagging` by their identity policy was refused a tagged `PutObject` that S3 allows, and the denial message wrongly said no identity-based policy allows `s3:PutObjectTagging`. Only gateways backed by the standalone IAM service (`--iam-standalone-endpoint`) were affected. `verifyResourceAccess` now returns one decision per action for each key. It computes them with `decisionFor` and parses the bucket policy once per request instead of once per key. `identityPolicyDecisions` now returns the `EvaluatePolicy` result without reducing it. `objectsAccessErrors` combines the two sources action by action. An explicit deny from the bucket, identity or session policy still wins and is reported as before. Otherwise an action is allowed when either source allows it, and, when a session policy is present, the session policy must also allow it. A request with any action not allowed is denied, and the denial names the first such action in list order, as S3 does. Each request still fetches the bucket policy once and makes one `EvaluatePolicy` round trip, and `VerifyObjectsAccess` still makes one round trip per action group.