Gateway supports the management of ACL for objects, including changes to existing authorizations.

Differences from S3

PUT /object?acl&versionId=X cannot be used because metadata on old versions is immutable.
Updating an object’s acl also creates a new version, updating the object’s modification time.
Gateway uses a convention whereby user names are decorated with {username}@{domain} or {username}+{tenant} depending on the idsys in which the user is defined. If the user is defined in the root idsys, then the decoration looks like {username}@. This decoration may be omitted if there cannot be any ambiguity, but, internally, Gateway always stores decorated usernames in the ACL owner and user grantees, adding it to an incoming ACL as needed and removing it where possible before passing an ACL back to the client.

GET Object ACL

GET Object acl uses the acl subresource to return the ACL of an object. To use this operation with S3, you must have READ_ACP access to the object.

The following request returns information, including the ACL, of an object:

GET /{object-name}?acl HTTP/1.1

GET Object Version ACL

The following request returns information, including the ACL, of a specific version of the object:

GET /{object-name}?version={etag}&acl HTTP/1.1

PUT Object ACL

PUT Object acl uses the acl subresource to send the ACL of an object in the request body (rather than in the request headers):

PUT /{object-name}?acl HTTP/1.1
 
<AccessControlPolicy>
  <Owner>
    <ID>ID</ID>
    <DisplayName>EmailAddress</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>ID</ID>
        <DisplayName>EmailAddress</DisplayName>
      </Grantee>
      <Permission>Permission</Permission>
    </Grant>
    ...
  </AccessControlList>
</AccessControlPolicy>

PUT Object Version ACL