Manage ACLs and object ownership

An ACL grants permissions to canonical users or S3 groups. It works alongside IAM, bucket policies and Block Public Access. An ACL permission therefore does not guarantee that access will be accepted. Object Ownership determines who owns objects and whether ACLs control access.

Prepare the account and permissions#

Open File > Accounts…, select the account, click Edit…, then open Capabilities > ACL policy. Enable ACL operations for this account enables the configured operations. Object ACL read scope and Object ACL write scope must allow the current object, or Current object and specific versions for versions. Set Bucket ACL response and Object ACL response according to what the service returns: the complete stored ACL, a filtered ACL, bucket permissions presented as an object ACL, or an ACL generated by the service. Available request forms and permissions also come from this policy. See capabilities before changing these advanced settings.

Usual permissions are s3:GetBucketAcl and s3:PutBucketAcl for a bucket, and s3:GetObjectAcl and s3:PutObjectAcl for an object. For a version, check s3:GetObjectVersionAcl and s3:PutObjectVersionAcl. Object Ownership uses s3:GetBucketOwnershipControls for reading and s3:PutBucketOwnershipControls for writing.

Enabling a local feature grants no permissions. Disabling the account’s ACL policy does not disable IAM or service policies.

Disable ACL operations in S3Client#

Uncheck Enable ACL operations for this account to prevent S3Client from reading or writing ACLs for that account. This local setting changes neither stored ACLs nor IAM permissions, bucket policies or the service’s Object Ownership mode.

Bucket, folder and object properties no longer offer an ACL tab. Explicit ACL choices for transfers and folder creation are unavailable. Other properties remain accessible under their own capability and permission rules, including Object Ownership.

Uploads, copies, moves, synchronization and folder marker creation that use the destination default continue without ACL requests or headers. This also applies to multipart and cross-account transfers. Content and property reads, tags, encryption and protections retain their own requirements.

For renames, storage class, metadata or encryption changes that require a copy, and Make current…, S3Client then chooses the destination default instead of requesting source ACL preservation. The same rule applies to recursive rewrites. If the service still uses ACLs, the rewritten object’s ACL and owner are not guaranteed to match the source, even within the same bucket.

An explicit ACL request is rejected with AclDisabled, including private or bucket-owner-full-control. An operation that expressly requires ACL preservation is rejected with AclPreservationImpossible; that requirement is not ignored. An ACL already loaded in memory does not bypass these denials. A write without an ACL does not trigger an ACL verification read.

Distinguish these situations:

Operations use the configuration captured during preparation. After changing the account, reopen the dialog and prepare a new operation to use the new settings.

Additional access log grants (TargetGrants) follow a separate capability; see Log bucket access.

Edit an ACL#

Properties for a single resource display its complete ACL. Properties for several objects group grantees together and let you prepare targeted changes for the whole selection. With Show versions on, the targets are the selected versions; otherwise, they are the current objects. A delete marker has no ACL.

For a single resource, saving replaces the complete ACL. Removing a grantee removes its ACL permissions without removing access granted by other policies. Granting permissions to a public group can expose data or modification rights; the application requests confirmation.

For a custom entry, Save this grantee in the account saves the grantee as soon as you click OK in the picker. Canceling properties afterward does not remove that entry from the account. Local alias is optional.

1. In the S3 pane, select the bucket, object or folder marker.
2. Open Properties, then ACL. For a bucket with an Object Ownership tab, the ACL tab is named Access control list (ACL).
3. Wait for loading; use Try again after a failed read.
4. If both modes are offered, select Individual permissions, then click Add.
5. In Choose an ACL grantee, choose from Available grantees or fill in Direct entry.
6. Choose Canonical user and enter its S3 canonical identifier, or S3 group and a URI allowed by the account. A canonical identifier is neither an access key nor an AWS account number.
7. For a canonical user, optionally enter Remote display name. To save the custom entry, select Save this grantee in the account and optionally enter Local alias.
8. Click OK and select permissions in the added row.
9. Use Remove for grantees to remove; check the entire ACL and warnings.
10. Click OK in properties and read the confirmations.
11. Reopen the ACL after completion to check the observed permissions.

Available groups depend on the policy. http://acs.amazonaws.com/groups/global/AllUsers includes anonymous access; http://acs.amazonaws.com/groups/global/AuthenticatedUsers covers all authenticated AWS accounts. http://acs.amazonaws.com/groups/s3/LogDelivery, when offered, is the S3 log delivery group. Check the group and its permissions before confirming.

The account policy may limit the number of ACL grants. A row with several permissions can count as several grants sent to the service. Counting rows alone is not enough to check this limit. Exceeding it blocks saving.

S3 may ignore the remote name. The alias remains in S3Client. Manage saved grantees in Accounts > Edit… > Saved ACL grantees with Add…, Edit… and Remove, then save the account. Removing a shortcut removes no remote permission. Copy grantee identifier in the context menu copies the raw identifier; Owner ID: also has a copy button. Long identifiers are shortened on screen; tooltips and copying retain the full value. Owner: displays the name returned by the service separately. The Display name column is hidden when no grantee has a name.

Full control covers the permissions applicable to the resource. The editor blocks rows without an identifier or permission, duplicates and permissions excluded by the account. A row of type Email remains visible but must be removed before saving an ACL built from the table; you cannot create these grantees. This restriction does not prevent replacement with a canned ACL.

Refresh reloads the ACL and asks you to confirm discarding local changes. Reset to private, when offered for the bucket, replaces all grants with full control for the owner. Preserve required access in a policy first: this command prepares to remove every other grant.

For a bucket or folder marker, S3Client rereads the ACL before saving. ACL changed asks you to confirm replacement if the remote ACL changed or comparison is incomplete. No reloads the remote ACL and discards local changes. Unable to verify ACL blocks saving and retains your changes. File properties do not use this conflict dialog.

Edit ACLs for several objects#

Select the objects or versions, then open Properties > ACL. The table shows how many successfully read targets contain each grantee and permission. It does not show a single ACL to apply to all objects.

Add and Edit open the permission choices: Keep unchanged, Allow on all selected objects or Remove from all selected objects. Remove prepares removal of the grantee from every target; Undo change discards the prepared change for that row. Check Change, then click OK in properties and reread the ACLs after the operation. Only explicitly prepared changes are applied; each object’s other permissions are preserved.

For exact versions, submit ACL and encryption changes separately. See properties for several objects for loading behavior and selection limits.

Apply a canned ACL to an existing resource#

In the S3 pane, select a single bucket, file or existing folder marker, then open Properties > ACL, or Access control list (ACL) for a bucket with an Object Ownership tab. After a successful read, Individual permissions and Predefined ACL modes are offered when the account policy allows the Canned ACL header form and at least one value for PutBucketAcl or PutObjectAcl, depending on the resource. With Show versions, the object target is the selected version; accounts limited to current-object ACL writes do not offer this change for a version. Virtual prefixes and delete markers do not offer this choice.

Individual permissions is selected initially and shows the observed permissions. If individual editing is unavailable, Read-only appears beside Permissions. An account can support replacement with a canned ACL while disallowing individual permission edits.

Predefined ACL replaces every ACL permission on the target. Select this mode, choose an allowed value in ACL, then click OK and review any confirmations. Values use S3 names and depend on the configured operation. The Amazon S3 policy offers private, public-read, public-read-write and authenticated-read for PutBucketAcl. For PutObjectAcl, it also offers aws-exec-read, bucket-owner-read and bucket-owner-full-control; these three values are not offered for a bucket. The table and Refresh are hidden in this mode: no preview of the resulting permissions is shown. Email grantees in the table are not sent back to the service.

Returning to Individual permissions restores the table draft. In that mode, Refresh asks for confirmation before discarding changes and returns to the observed permissions. Cancelling properties does not apply the canned ACL.

A failed read, a generated ACL, a bucket-derived ACL or an Object Ownership restriction does not enable Predefined ACL. For an object, changing metadata, storage or encryption at the same time may require a copy; that operation’s policy must also allow the selected ACL. For a bucket, the ACL is reread before writing; the ACL changed and Unable to verify ACL confirmations described above also apply to canned replacement. Reopen properties after completion to check the observed permissions.

Canned ACLs and folder creation#

Open the parent folder in list view, or select it in the tree, then use Create folder with an ACL… in the context menu. This command applies a Canned ACL to the new marker. Depending on the policy, choices include Private, Public read, Public read and write, Authenticated users read, AWS execution read, Bucket owner read and Bucket owner full control. Only choices allowed for the operation appear; the first is selected initially, which is not necessarily Private. Choose a value, click OK and confirm any public ACL. In the pane, then name New folder and press Enter; check the folder after completion.

Public read includes anonymous users. Authenticated users read covers all authenticated AWS accounts, not just your organization. Bucket owner full control grants full control to the bucket owner and can affect ownership with Bucket owner preferred.

Private grants ACL permissions only to the object owner. Public read and write adds public grants, but WRITE does not apply to an object marker. AWS execution read lets EC2 read an AMI bundle. Bucket owner read grants read access to the bucket owner. Amazon S3 canned ACLs.

A virtual prefix has no ACL; without a corresponding marker, its properties offer no ACL editor. A marker’s ACL does not apply to descendants. For those, use Modify child objects… or Modify child object versions…, described in bulk changes.

Choose Object Ownership#

In Accounts > Edit… > Capabilities > Object Ownership, Read Object Ownership settings and Change Object Ownership settings must match the service’s support. The tab is offered only for a General purpose bucket with at least one of these capabilities. Its actions depend on the available capabilities.

Before choosing Bucket owner enforced, the bucket ACL must grant full control to its owner and no permissions to other grantees. Remove other ACL grants and provide the required access through service policies. ACLs remain stored but stop controlling access. Reenabling ACLs can restore the access they previously granted.

1. Select a single bucket and open Properties > Object Ownership.
2. Under Ownership mode, identify the remote mode by Current and ACLs enabled or ACLs disabled.
3. Select the radio button for the desired mode. Current continues to mark the remote mode while you prepare your choice.
4. For Bucket owner enforced, correct the bucket ACL first.
5. Click OK and check change or replacement confirmations.
6. Reopen properties to check the mode. After reenabling ACLs, reopen the ACL too.

When the remote mode has not been established, Current mode: displays its state: Not loaded before reading, Not configured (ACLs enabled) if no explicit mode is set, or Unknown if the mode could not be established. Not configured (ACLs enabled) means the historical behavior with ACLs enabled. If writing is allowed but reading is unavailable, S3Client warns that it may replace an unverified configuration. A remote change since opening can also require replacement or reloading.

Restrictions and verification#

An ACL may be read-only because of Object Ownership, the account policy, or a response generated or derived from the bucket. If bucket permissions are displayed as an object ACL, you cannot save them as that object’s own ACL. AccessDenied means access was refused; it does not prove that the API is unsupported.

If the service hides grants, replacing the displayed ACL or rewriting an object can lose invisible permissions; S3Client warns about this risk. A public write may be accepted without being confirmed by rereading. An unverified result does not prove actual access: check the reread permissions, then the grantee’s access when it matters.

Bucket permissions projected onto a version#

In the S3 pane, enable Show versions, select an existing file version or folder-marker version, then open Properties > ACL. When the account allows version ACL reads and Object ACL response is Object ACL derived from the bucket ACL, S3Client displays the bucket-derived permissions as read-only. They are not an independent ACL stored with that version or a record of permissions at the time it was created. Reading them does not enable editing or exact preservation as an object ACL during a copy. Delete markers and virtual prefixes have no object ACL to display.