# Managing access with ACLs Access control lists (ACLs) are one of the resource-based options that you can use to manage access to your buckets and objects. You can use ACLs to grant basic read/write permissions to other AWS accounts. There are limits to managing permissions using ACLs. For example, you can grant permissions only to other AWS accounts; you cannot grant permissions to users in your account. You cannot grant conditional permissions, nor can you explicitly deny permissions. ACLs are suitable for specific scenarios. For example, if a bucket owner allows other AWS accounts to upload objects, permissions to these objects can only be managed using object ACL by the AWS account that owns the object. S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to both control ownership of the objects that are uploaded to your bucket and to disable or enable ACLs. By default, Object Ownership is set to the Bucket owner enforced setting, and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to them exclusively by using access-management policies. A majority of modern use cases in Amazon S3 no longer require the use of ACLs. We recommend that you keep ACLs disabled, except in circumstances where you need to control access for each object individually. With ACLs disabled, you can use policies to control access to all objects in your bucket, regardless of who uploaded the objects to your bucket. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md). **Important** If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set access control lists (ACLs) or update ACLs fail and return the `AccessControlListNotSupported` error code. Requests to read ACLs are still supported. For more information about ACLs, see the following topics. **Topics** + [ # Access control list (ACL) overview ](acl-overview.md) + [ # Configuring ACLs ](managing-acls.md) + [ # Policy examples for ACLs ](example-bucket-policies-condition-keys.md) # Access control list (ACL) overview Amazon S3 access control lists (ACLs) enable you to manage access to buckets and objects. Each bucket and object has an ACL attached to it as a subresource. It defines which AWS accounts or groups are granted access and the type of access. When a request is received against a resource, Amazon S3 checks the corresponding ACL to verify that the requester has the necessary access permissions. S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to both control ownership of the objects that are uploaded to your bucket and to disable or enable ACLs. By default, Object Ownership is set to the Bucket owner enforced setting, and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to them exclusively by using access-management policies. A majority of modern use cases in Amazon S3 no longer require the use of ACLs. We recommend that you keep ACLs disabled, except in circumstances where you need to control access for each object individually. With ACLs disabled, you can use policies to control access to all objects in your bucket, regardless of who uploaded the objects to your bucket. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md). **Important** If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set access control lists (ACLs) or update ACLs fail and return the `AccessControlListNotSupported` error code. Requests to read ACLs are still supported. When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource. This is shown in the following sample bucket ACL (the default object ACL has the same structure): **Example** ``` 1. 2. 3. 4. *** Owner-Canonical-User-ID *** 5. 6. 7. 8. 10. *** Owner-Canonical-User-ID *** 11. 12. FULL_CONTROL 13. 14. 15. ``` The sample ACL includes an `Owner` element that identifies the owner by the AWS account's canonical user ID. For instructions on finding your canonical user ID, see [Finding an AWS account canonical user ID](#finding-canonical-id). The `Grant` element identifies the grantee (either an AWS account or a predefined group) and the permission granted. This default ACL has one `Grant` element for the owner. You grant permissions by adding `Grant` elements, with each grant identifying the grantee and the permission. **Note** An ACL can have up to 100 grants. **Topics** + [ ## Who is a grantee? ](#specifying-grantee) + [ ## What permissions can I grant? ](#permissions) + [ ## `aclRequired` values for common Amazon S3 requests ](#aclrequired-s3) + [ ## Sample ACL ](#sample-acl) + [ ## Canned ACL ](#canned-acl) ## Who is a grantee? When you grant access rights, you specify each grantee as a `type="value"` pair, where `type` is one of the following: + `id` – If the value specified is the canonical user ID of an AWS account + `uri` – If you are granting permissions to a predefined group **Warning** When you grant other AWS accounts access to your resources, be aware that the AWS accounts can delegate their permissions to users under their accounts. This is known as *cross-account access*. For information about using cross-account access, see [ Creating a Role to Delegate Permissions to an IAM User](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*. ### Finding an AWS account canonical user ID The canonical user ID is associated with your AWS account. This ID is a long string of characters, such as: `79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be` For information about how to find the canonical user ID for your account, see [Find the canonical user ID for your AWS account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) in the *AWS Account Management Reference Guide*. You can also look up the canonical user ID of an AWS account by reading the ACL of a bucket or an object to which the AWS account has access permissions. When an individual AWS account is granted permissions by a grant request, a grant entry is added to the ACL with the account's canonical user ID. **Note** If you make your bucket public (not recommended), any unauthenticated user can upload objects to the bucket. These anonymous users don't have an AWS account. When an anonymous user uploads an object to your bucket, Amazon S3 adds a special canonical user ID (`65a011a29cdf8ec533ec3d1ccaae921c`) as the object owner in the ACL. For more information, see [Amazon S3 bucket and object ownership](access-policy-language-overview.md#about-resource-owner). ### Amazon S3 predefined groups Amazon S3 has a set of predefined groups. When granting account access to a group, you specify one of the Amazon S3 URIs instead of a canonical user ID. Amazon S3 provides the following predefined groups: + ****Authenticated Users group**** – Represented by `http://acs.amazonaws.com/groups/global/AuthenticatedUsers`. This group represents all AWS accounts. **Access permission to this group allows any AWS account to access the resource.** However, all requests must be signed (authenticated). **Warning** When you grant access to the **Authenticated Users group**, any AWS authenticated user in the world can access your resource. + ****All Users group**** – Represented by `http://acs.amazonaws.com/groups/global/AllUsers`. **Access permission to this group allows anyone in the world access to the resource.** The requests can be signed (authenticated) or unsigned (anonymous). Unsigned requests omit the Authentication header in the request. **Warning** We highly recommend that you never grant the **All Users group** `WRITE`, `WRITE_ACP`, or `FULL_CONTROL` permissions. For example, although `WRITE` permissions deny non-owners the ability to overwrite or delete existing objects, `WRITE` permissions still allow anyone to store objects in your bucket, for which you are billed. For more details about these permissions, see the following section [What permissions can I grant?](#permissions). + ****Log Delivery group**** – Represented by `http://acs.amazonaws.com/groups/s3/LogDelivery`. `WRITE` permission on a bucket enables this group to write server access logs (see [Logging requests with server access logging](ServerLogs.md)) to the bucket. **Note** When using ACLs, a grantee can be an AWS account or one of the predefined Amazon S3 groups. However, the grantee cannot be an IAM user. For more information about AWS users and permissions within IAM, see [Using AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/). ## What permissions can I grant? The following table lists the set of permissions that Amazon S3 supports in an ACL. The set of ACL permissions is the same for an object ACL and a bucket ACL. However, depending on the context (bucket ACL or object ACL), these ACL permissions grant permissions for specific buckets or object operations. The table lists the permissions and describes what they mean in the context of objects and buckets. For more information about ACL permissions in the Amazon S3 console, see [Configuring ACLs](managing-acls.md). | Permission | When granted on a bucket | When granted on an object | | --- | --- | --- | | READ | Allows grantee to list the objects in the bucket | Allows grantee to read the object data and its metadata | | WRITE | Allows grantee to create new objects in the bucket. For the bucket and object owners of existing objects, also allows deletions and overwrites of those objects | Not applicable | | READ\$1ACP | Allows grantee to read the bucket ACL | Allows grantee to read the object ACL | | WRITE\$1ACP | Allows grantee to write the ACL for the applicable bucket | Allows grantee to write the ACL for the applicable object | | FULL\$1CONTROL | Allows grantee the READ, WRITE, READ\$1ACP, and WRITE\$1ACP permissions on the bucket | Allows grantee the READ, READ\$1ACP, and WRITE\$1ACP permissions on the object | **Warning** Use caution when granting access permissions to your S3 buckets and objects. For example, granting `WRITE` access to a bucket allows the grantee to create objects in the bucket. We highly recommend that you read through the entire [Access control list (ACL) overview](#acl-overview) section before granting permissions. ### Mapping of ACL permissions and access policy permissions As shown in the preceding table, an ACL allows only a finite set of permissions, compared to the number of permissions that you can set in an access policy (see [Policy actions for Amazon S3](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-actions)). Each of these permissions allows one or more Amazon S3 operations. The following table shows how each ACL permission maps to the corresponding access policy permissions. As you can see, access policy allows more permissions than an ACL does. You use ACLs primarily to grant basic read/write permissions, similar to file system permissions. For more information about when to use an ACL, see [Identity and Access Management for Amazon S3](security-iam.md). For more information about ACL permissions in the Amazon S3 console, see [Configuring ACLs](managing-acls.md). | ACL permission | Corresponding access policy permissions when the ACL permission is granted on a bucket | Corresponding access policy permissions when the ACL permission is granted on an object | | --- | --- | --- | | READ | s3:ListBucket, s3:ListBucketVersions, and s3:ListBucketMultipartUploads | s3:GetObject and s3:GetObjectVersion | | WRITE | `s3:PutObject` Bucket owner can create, overwrite, and delete any object in the bucket, and object owner has `FULL_CONTROL` over their object. In addition, when the grantee is the bucket owner, granting `WRITE` permission in a bucket ACL allows the `s3:DeleteObjectVersion` action to be performed on any version in that bucket. | Not applicable | | READ\$1ACP | s3:GetBucketAcl | s3:GetObjectAcl and s3:GetObjectVersionAcl | | WRITE\$1ACP | s3:PutBucketAcl | s3:PutObjectAcl and s3:PutObjectVersionAcl | | FULL\$1CONTROL | Equivalent to granting READ, WRITE, READ\$1ACP, and WRITE\$1ACP ACL permissions. Accordingly, this ACL permission maps to a combination of corresponding access policy permissions. | Equivalent to granting READ, READ\$1ACP, and WRITE\$1ACP ACL permissions. Accordingly, this ACL permission maps to a combination of corresponding access policy permissions. | ### Condition keys When you grant access policy permissions, you can use condition keys to constrain the value for the ACL on an object using a bucket policy. The following context keys correspond to ACLs. You can use these context keys to mandate the use of a specific ACL in a request: + `s3:x-amz-grant-read` ‐ Require read access. + `s3:x-amz-grant-write` ‐ Require write access. + `s3:x-amz-grant-read-acp` ‐ Require read access to the bucket ACL. + `s3:x-amz-grant-write-acp` ‐ Require write access to the bucket ACL. + `s3:x-amz-grant-full-control` ‐ Require full control. + `s3:x-amz-acl` ‐ Require a [Canned ACL](#canned-acl). For example policies that involve ACL-specific headers, see [Granting s3:PutObject permission with a condition requiring the bucket owner to get full control](example-bucket-policies-condition-keys.md#grant-putobject-conditionally-1). For a complete list of Amazon S3 specific condition keys, see [ Actions, resources, and condition keys for Amazon S3](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html) in the *Service Authorization Reference*. For more information about the permissions to S3 API operations by S3 resource types, see [Required permissions for Amazon S3 API operations](using-with-s3-policy-actions.md). ## `aclRequired` values for common Amazon S3 requests To identify Amazon S3 requests that required ACLs for authorization, you can use the `aclRequired` value in Amazon S3 server access logs or AWS CloudTrail. The `aclRequired` value that appears in CloudTrail or Amazon S3 server access logs depends on which operations were called and certain information about the requester, object owner, and bucket owner. If no ACLs were required, or if you are setting the `bucket-owner-full-control` canned ACL, or if the requests are allowed by your bucket policy, the `aclRequired` value string is "`-`" in Amazon S3 server access logs and is absent in CloudTrail. The following tables list the expected `aclRequired` values in CloudTrail or Amazon S3 server access logs for the various Amazon S3 API operations. You can use this information to understand which Amazon S3 operations depend on ACLs for authorization. In the following tables, A, B, and C represent the different accounts associated with the requester, object owner, and bucket owner. Entries with an asterisk (\$1) indicate any of accounts A, B, or C. **Note** `PutObject` operations in the following table, unless specified otherwise, indicate requests that do not set an ACL, unless the ACL is a `bucket-owner-full-control` ACL. A null value for `aclRequired` indicates that `aclRequired` is absent in AWS CloudTrail logs. The following table shows the `aclRequired` values for CloudTrail. | Operation name | Requester | Object owner | Bucket owner | Bucket policy grants access | `aclRequired` value | Reason | | --- | --- | --- | --- | --- | --- | --- | | GetObject | A | A | A | Yes or No | null | Same-account access | | GetObject | A | B | A | Yes or No | null | Same-account access with bucket owner enforced | | GetObject | A | A | B | Yes | null | Cross-account access granted by bucket policy | | GetObject | A | A | B | No | Yes | Cross-account access relies on ACL | | GetObject | A | A | B | Yes | null | Cross-account access granted by bucket policy | | GetObject | A | B | B | No | Yes | Cross-account access relies on ACL | | GetObject | A | B | C | Yes | null | Cross-account access granted by bucket policy | | GetObject | A | B | C | No | Yes | Cross-account access relies on ACL | | PutObject | A | Not applicable | A | Yes or No | null | Same-account access | | PutObject | A | Not applicable | B | Yes | null | Cross-account access granted by bucket policy | | PutObject | A | Not applicable | B | No | Yes | Cross-account access relies on ACL | | PutObject with an ACL (except for bucket-owner-full-control) | \$1 | Not applicable | \$1 | Yes or No | Yes | Request grants ACL | | ListObjects | A | Not applicable | A | Yes or No | null | Same-account access | | ListObjects | A | Not applicable | B | Yes | null | Cross-account access granted by bucket policy | | ListObjects | A | Not applicable | B | No | Yes | Cross-account access relies on ACL | | DeleteObject | A | Not applicable | A | Yes or No | null | Same-account access | | DeleteObject | A | Not applicable | B | Yes | null | Cross-account access granted by bucket policy | | DeleteObject | A | Not applicable | B | No | Yes | Cross-account access relies on ACL | | PutObjectAcl | \$1 | \$1 | \$1 | Yes or No | Yes | Request grants ACL | | PutBucketAcl | \$1 | Not applicable | \$1 | Yes or No | Yes | Request grants ACL | **Note** `REST.PUT.OBJECT` operations in the following table, unless specified otherwise, indicate requests that do not set an ACL, unless the ACL is a `bucket-owner-full-control` ACL. An `aclRequired` value string of "`-`" indicates a null value in Amazon S3 server access logs. The following table shows the `aclRequired` values for Amazon S3 server access logs. | Operation name | Requester | Object owner | Bucket owner | Bucket policy grants access | `aclRequired` value | Reason | | --- | --- | --- | --- | --- | --- | --- | | REST.GET.OBJECT | A | A | A | Yes or No | - | Same-account access | | REST.GET.OBJECT | A | B | A | Yes or No | - | Same-account access with bucket owner enforced | | REST.GET.OBJECT | A | A | B | Yes | - | Cross-account access granted by bucket policy | | REST.GET.OBJECT | A | A | B | No | Yes | Cross-account access relies on ACL | | REST.GET.OBJECT | A | B | B | Yes | - | Cross-account access granted by bucket policy | | REST.GET.OBJECT | A | B | B | No | Yes | Cross-account access relies on ACL | | REST.GET.OBJECT | A | B | C | Yes | - | Cross-account access granted by bucket policy | | REST.GET.OBJECT | A | B | C | No | Yes | Cross-account access relies on ACL | | REST.PUT.OBJECT | A | Not applicable | A | Yes or No | - | Same-account access | | REST.PUT.OBJECT | A | Not applicable | B | Yes | - | Cross-account access granted by bucket policy | | REST.PUT.OBJECT | A | Not applicable | B | No | Yes | Cross-account access relies on ACL | | REST.PUT.OBJECT with an ACL (except for bucket-owner-full-control) | \$1 | Not applicable | \$1 | Yes or No | Yes | Request grants ACL | | REST.GET.BUCKET | A | Not applicable | A | Yes or No | - | Same-account access | | REST.GET.BUCKET | A | Not applicable | B | Yes | - | Cross-account access granted by bucket policy | | REST.GET.BUCKET | A | Not applicable | B | No | Yes | Cross-account access relies on ACL | | REST.DELETE.OBJECT | A | Not applicable | A | Yes or No | - | Same-account access | | REST.DELETE.OBJECT | A | Not applicable | B | Yes | - | Cross-account access granted by bucket policy | | REST.DELETE.OBJECT | A | Not applicable | B | No | Yes | Cross-account access relies on ACL | | REST.PUT.ACL | \$1 | \$1 | \$1 | Yes or No | Yes | Request grants ACL | ## Sample ACL The following sample ACL on a bucket identifies the resource owner and a set of grants. The format is the XML representation of an ACL in the Amazon S3 REST API. The bucket owner has `FULL_CONTROL` of the resource. In addition, the ACL shows how permissions are granted on a resource to two AWS accounts, identified by canonical user ID, and two of the predefined Amazon S3 groups discussed in the preceding section. **Example** ``` 1. 2. 3. 4. Owner-canonical-user-ID 5. 6. 7. 8. 9. Owner-canonical-user-ID 10. 11. FULL_CONTROL 12. 13. 14. 15. 16. user1-canonical-user-ID 17. 18. WRITE 19. 20. 21. 22. 23. user2-canonical-user-ID 24. 25. READ 26. 27. 28. 29. 30. http://acs.amazonaws.com/groups/global/AllUsers 31. 32. READ 33. 34. 35. 36. http://acs.amazonaws.com/groups/s3/LogDelivery 37. 38. WRITE 39. 40. 41. 42. ``` ## Canned ACL Amazon S3 supports a set of predefined grants, known as *canned ACLs*. Each canned ACL has a predefined set of grantees and permissions. The following table lists the set of canned ACLs and the associated predefined grants. | Canned ACL | Applies to | Permissions added to ACL | | --- | --- | --- | | private | Bucket and object | Owner gets FULL\$1CONTROL. No one else has access rights (default). | | public-read | Bucket and object | Owner gets FULL\$1CONTROL. The AllUsers group (see [Who is a grantee?](#specifying-grantee)) gets READ access. | | public-read-write | Bucket and object | Owner gets FULL\$1CONTROL. The AllUsers group gets READ and WRITE access. Granting this on a bucket is generally not recommended. | | aws-exec-read | Bucket and object | Owner gets FULL\$1CONTROL. Amazon EC2 gets READ access to GET an Amazon Machine Image (AMI) bundle from Amazon S3. | | authenticated-read | Bucket and object | Owner gets FULL\$1CONTROL. The AuthenticatedUsers group gets READ access. | | bucket-owner-read | Object | Object owner gets FULL\$1CONTROL. Bucket owner gets READ access. If you specify this canned ACL when creating a bucket, Amazon S3 ignores it. | | bucket-owner-full-control | Object | Both the object owner and the bucket owner get FULL\$1CONTROL over the object. If you specify this canned ACL when creating a bucket, Amazon S3 ignores it. | | log-delivery-write | Bucket | The LogDelivery group gets WRITE and READ\$1ACP permissions on the bucket. For more information about logs, see ([Logging requests with server access logging](ServerLogs.md)). | **Note** You can specify only one of these canned ACLs in your request. You specify a canned ACL in your request by using the `x-amz-acl` request header. When Amazon S3 receives a request with a canned ACL in the request, it adds the predefined grants to the ACL of the resource. # Configuring ACLs This section explains how to manage access permissions for S3 buckets and objects using access control lists (ACLs). You can add grants to your resource ACL using the AWS Management Console, AWS Command Line Interface (CLI), REST API, or AWS SDKs. Bucket and object permissions are independent of each other. An object does not inherit the permissions from its bucket. For example, if you create a bucket and grant write access to a user, you can't access that user’s objects unless the user explicitly grants you access. You can grant permissions to other AWS account users or to predefined groups. The user or group that you are granting permissions to is called the *grantee*. By default, the owner, which is the AWS account that created the bucket, has full permissions. Each permission you grant for a user or group adds an entry in the ACL that is associated with the bucket. The ACL lists grants, which identify the grantee and the permission granted. S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to both control ownership of the objects that are uploaded to your bucket and to disable or enable ACLs. By default, Object Ownership is set to the Bucket owner enforced setting, and all ACLs are disabled. When ACLs are disabled, the bucket owner owns all the objects in the bucket and manages access to them exclusively by using access-management policies. A majority of modern use cases in Amazon S3 no longer require the use of ACLs. We recommend that you keep ACLs disabled, except in circumstances where you need to control access for each object individually. With ACLs disabled, you can use policies to control access to all objects in your bucket, regardless of who uploaded the objects to your bucket. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](about-object-ownership.md). **Important** If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set access control lists (ACLs) or update ACLs fail and return the `AccessControlListNotSupported` error code. Requests to read ACLs are still supported. **Warning** We highly recommend that you avoid granting write access to the **Everyone (public access)** or **Authenticated Users group (all AWS authenticated users)** groups. For more information about the effects of granting write access to these groups, see [Amazon S3 predefined groups](acl-overview.md#specifying-grantee-predefined-groups). ## Using the S3 console to set ACL permissions for a bucket The console displays combined access grants for duplicate grantees. To see the full list of ACLs, use the Amazon S3 REST API, AWS CLI, or AWS SDKs. The following table shows the ACL permissions that you can configure for buckets in the Amazon S3 console. **Amazon S3 console ACL permissions for buckets** | Console permission | ACL permission | Access | | --- | --- | --- | | Objects - List | READ | Allows grantee to list the objects in the bucket. | | Objects - Write | WRITE | Allows grantee to create new objects in the bucket. For the bucket and object owners of existing objects, also allows deletions and overwrites of those objects. | | Bucket ACL - Read | READ\$1ACP | Allows grantee to read the bucket ACL. | | Bucket ACL - Write | WRITE\$1ACP | Allows grantee to write the ACL for the applicable bucket. | | Everyone (public access): Objects - List | READ | Grants public read access for the objects in the bucket. When you grant list access to Everyone (public access), anyone in the world can access the objects in the bucket. | | Everyone (public access): Bucket ACL - Read | READ\$1ACP | Grants public read access for the bucket ACL. When you grant read access to Everyone (public access), anyone in the world can access the bucket ACL. | For more information about ACL permissions, see [Access control list (ACL) overview](acl-overview.md). **Important** If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set access control lists (ACLs) or update ACLs fail and return the `AccessControlListNotSupported` error code. Requests to read ACLs are still supported. **To set ACL permissions for a bucket** 1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. In the left navigation pane, choose **General purpose buckets**. 1. In the **Buckets** list, choose the name of the bucket that you want to set permissions for. 1. Choose **Permissions**. 1. Under **Access control list**, choose **Edit**. You can edit the following ACL permissions for the bucket: **Objects** + **List** – Allows a grantee to list the objects in the bucket. + **Write** – Allows grantee to create new objects in the bucket. For the bucket and object owners of existing objects, also allows deletions and overwrites of those objects. In the S3 console, you can only grant write access to the S3 log delivery group and the bucket owner (your AWS account). We highly recommend that you do not grant write access for other grantees. However, if you need to grant write access, you can use the AWS CLI, AWS SDKs, or the REST API. **Bucket ACL** + **Read** – Allows grantee to read the bucket ACL. + **Write** – Allows grantee to write the ACL for the applicable bucket. 1. To change the bucket owner's permissions, beside **Bucket owner (your AWS account)**, clear or select from the following ACL permissions: + **Objects** – **List** or **Write** + **Bucket ACL** – **Read** or **Write** The *owner* refers to the AWS account root user, not an AWS Identity and Access Management IAM user. For more information about the root user, see [The AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) in the *IAM User Guide*. 1. To grant or undo permissions for the general public (everyone on the internet), beside **Everyone (public access)**, clear or select from the following ACL permissions: + **Objects** – **List** + **Bucket ACL** – **Read** **Warning** Use caution when granting the **Everyone** group public access to your S3 bucket. When you grant access to this group, anyone in the world can access your bucket. We highly recommend that you never grant any kind of public write access to your S3 bucket. 1. To grant or undo permissions for anyone with an AWS account, beside **Authenticated Users group (anyone with an AWS account)**, clear or select from the following ACL permissions: + **Objects** – **List** + **Bucket ACL** – **Read** 1. To grant or undo permissions for Amazon S3 to write server access logs to the bucket, under **S3 log delivery group**, clear or select from the following ACL permissions: + **Objects** – **List** or **Write** + **Bucket ACL** – **Read** or **Write** If a bucket is set up as the target bucket to receive access logs, the bucket permissions must allow the **Log Delivery** group write access to the bucket. When you enable server access logging on a bucket, the Amazon S3 console grants write access to the **Log Delivery** group for the target bucket that you choose to receive the logs. For more information about server access logging, see [Enabling Amazon S3 server access logging](enable-server-access-logging.md). 1. To grant access to another AWS account, do the following: 1. Choose **Add grantee**. 1. In the **Grantee** box, enter the canonical ID of the other AWS account. 1. Select from the following ACL permissions: + **Objects** – **List** or **Write** + **Bucket ACL** – **Read** or **Write** **Warning** When you grant other AWS accounts access to your resources, be aware that the AWS accounts can delegate their permissions to users under their accounts. This is known as *cross-account access*. For information about using cross-account access, see [ Creating a Role to Delegate Permissions to an IAM User](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*. 1. To remove access to another AWS account, under **Access for other AWS accounts**, choose **Remove**. 1. To save your changes, choose **Save changes**. ## Using the S3 console to set ACL permissions for an object The console displays combined access grants for duplicate grantees. To see the full list of ACLs, use the Amazon S3 REST API, AWS CLI, or AWS SDKs. The following table shows the ACL permissions that you can configure for objects in the Amazon S3 console. **Amazon S3 console ACL permissions for objects** | Console permission | ACL permission | Access | | --- | --- | --- | | Object - Read | READ | Allows grantee to read the object data and its metadata. | | Object ACL - Read | READ\$1ACP | Allows grantee to read the object ACL. | | Object ACL - Write | WRITE\$1ACP | Allows grantee to write the ACL for the applicable object | For more information about ACL permissions, see [Access control list (ACL) overview](acl-overview.md). **Important** If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set access control lists (ACLs) or update ACLs fail and return the `AccessControlListNotSupported` error code. Requests to read ACLs are still supported. **To set ACL permissions for an object** 1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. In the **Buckets** list, choose the name of the bucket that contains the object. 1. In the **objects** list, choose the name of the object for which you want to set permissions. 1. Choose **Permissions**. 1. Under Access control list (ACL), choose **Edit**. You can edit the following ACL permissions for the object: **Object** + **Read** – Allows grantee to read the object data and its metadata. **Object ACL** + **Read** – Allows grantee to read the object ACL. + **Write** – Allows grantee to write the ACL for the applicable object. In the S3 console, you can only grant write access to the bucket owner (your AWS account). We highly recommend that you do not grant write access for other grantees. However, if you need to grant write access, you can use the AWS CLI, AWS SDKs, or the REST API. 1. You can manage object access permissions for the following: 1. **Access for object owner** The *owner* refers to the AWS account root user, and not an AWS Identity and Access Management IAM user. For more information about the root user, see [The AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) in the *IAM User Guide*. To change the owner's object access permissions, under **Access for object owner**, choose **Your AWS Account (owner)**. Select the check boxes for the permissions that you want to change, and then choose **Save**. 1. **Access for other AWS accounts** To grant permissions to an AWS user from a different AWS account, under **Access for other AWS accounts**, choose **Add account**. In the **Enter an ID** field, enter the canonical ID of the AWS user that you want to grant object permissions to. For information about finding a canonical ID, see [Your AWS account identifiers](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) in the *Amazon Web Services General Reference*. You can add as many as 99 users. Select the check boxes for the permissions that you want to grant to the user, and then choose **Save**. To display information about the permissions, choose the Help icons. 1. **Public access** To grant access to your object to the general public (everyone in the world), under **Public access**, choose **Everyone**. Granting public access permissions means that anyone in the world can access the object. Select the check boxes for the permissions that you want to grant, and then choose **Save**. **Warning** Use caution when granting the **Everyone** group anonymous access to your Amazon S3 objects. When you grant access to this group, anyone in the world can access your object. If you need to grant access to everyone, we highly recommend that you only grant permissions to **Read objects**. We highly recommend that you *do not* grant the **Everyone** group write object permissions. Doing so allows anyone to overwrite the ACL permissions for the object. ## Using the AWS SDKs This section provides examples of how to configure access control list (ACL) grants on buckets and objects. **Important** If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set access control lists (ACLs) or update ACLs fail and return the `AccessControlListNotSupported` error code. Requests to read ACLs are still supported. ------ #### [ Java ] This section provides examples of how to configure access control list (ACL) grants on buckets and objects. The first example creates a bucket with a canned ACL (see [Canned ACL](acl-overview.md#canned-acl)), creates a list of custom permission grants, and then replaces the canned ACL with an ACL containing the custom grants. The second example shows how to modify an ACL using the `AccessControlList.grantPermission()` method. **Example Create a bucket and specify a canned ACL that grants permission to the S3 log delivery group** This example creates a bucket. In the request, the example specifies a canned ACL that grants the Log Delivery group permission to write logs to the bucket. ``` import com.amazonaws.AmazonServiceException; import com.amazonaws.SdkClientException; import com.amazonaws.regions.Regions; import com.amazonaws.services.s3.AmazonS3; import com.amazonaws.services.s3.AmazonS3ClientBuilder; import com.amazonaws.services.s3.model.*; import java.io.IOException; import java.util.ArrayList; public class CreateBucketWithACL { public static void main(String[] args) throws IOException { Regions clientRegion = Regions.DEFAULT_REGION; String bucketName = "*** Bucket name ***"; String userEmailForReadPermission = "*** user@example.com ***"; try { AmazonS3 s3Client = AmazonS3ClientBuilder.standard() .withRegion(clientRegion) .build(); // Create a bucket with a canned ACL. This ACL will be replaced by the // setBucketAcl() // calls below. It is included here for demonstration purposes. CreateBucketRequest createBucketRequest = new CreateBucketRequest(bucketName, clientRegion.getName()) .withCannedAcl(CannedAccessControlList.LogDeliveryWrite); s3Client.createBucket(createBucketRequest); // Create a collection of grants to add to the bucket. ArrayList grantCollection = new ArrayList(); // Grant the account owner full control. Grant grant1 = new Grant(new CanonicalGrantee(s3Client.getS3AccountOwner().getId()), Permission.FullControl); grantCollection.add(grant1); // Grant the LogDelivery group permission to write to the bucket. Grant grant2 = new Grant(GroupGrantee.LogDelivery, Permission.Write); grantCollection.add(grant2); // Save grants by replacing all current ACL grants with the two we just created. AccessControlList bucketAcl = new AccessControlList(); bucketAcl.grantAllPermissions(grantCollection.toArray(new Grant[0])); s3Client.setBucketAcl(bucketName, bucketAcl); // Retrieve the bucket's ACL, add another grant, and then save the new ACL. AccessControlList newBucketAcl = s3Client.getBucketAcl(bucketName); Grant grant3 = new Grant(new EmailAddressGrantee(userEmailForReadPermission), Permission.Read); newBucketAcl.grantAllPermissions(grant3); s3Client.setBucketAcl(bucketName, newBucketAcl); } catch (AmazonServiceException e) { // The call was transmitted successfully, but Amazon S3 couldn't process // it and returned an error response. e.printStackTrace(); } catch (SdkClientException e) { // Amazon S3 couldn't be contacted for a response, or the client // couldn't parse the response from Amazon S3. e.printStackTrace(); } } } ``` **Example Update ACL on an existing object** This example updates the ACL on an object. The example performs the following tasks: + Retrieves an object's ACL + Clears the ACL by removing all existing permissions + Adds two permissions: full access to the owner, and WRITE\$1ACP (see [What permissions can I grant?](acl-overview.md#permissions)) to a user identified by an email address + Saves the ACL to the object ``` import com.amazonaws.AmazonServiceException; import com.amazonaws.SdkClientException; import com.amazonaws.auth.profile.ProfileCredentialsProvider; import com.amazonaws.regions.Regions; import com.amazonaws.services.s3.AmazonS3; import com.amazonaws.services.s3.AmazonS3ClientBuilder; import com.amazonaws.services.s3.model.AccessControlList; import com.amazonaws.services.s3.model.CanonicalGrantee; import com.amazonaws.services.s3.model.EmailAddressGrantee; import com.amazonaws.services.s3.model.Permission; import java.io.IOException; public class ModifyACLExistingObject { public static void main(String[] args) throws IOException { Regions clientRegion = Regions.DEFAULT_REGION; String bucketName = "*** Bucket name ***"; String keyName = "*** Key name ***"; String emailGrantee = "*** user@example.com ***"; try { AmazonS3 s3Client = AmazonS3ClientBuilder.standard() .withCredentials(new ProfileCredentialsProvider()) .withRegion(clientRegion) .build(); // Get the existing object ACL that we want to modify. AccessControlList acl = s3Client.getObjectAcl(bucketName, keyName); // Clear the existing list of grants. acl.getGrantsAsList().clear(); // Grant a sample set of permissions, using the existing ACL owner for Full // Control permissions. acl.grantPermission(new CanonicalGrantee(acl.getOwner().getId()), Permission.FullControl); acl.grantPermission(new EmailAddressGrantee(emailGrantee), Permission.WriteAcp); // Save the modified ACL back to the object. s3Client.setObjectAcl(bucketName, keyName, acl); } catch (AmazonServiceException e) { // The call was transmitted successfully, but Amazon S3 couldn't process // it, so it returned an error response. e.printStackTrace(); } catch (SdkClientException e) { // Amazon S3 couldn't be contacted for a response, or the client // couldn't parse the response from Amazon S3. e.printStackTrace(); } } } ``` ------ #### [ .NET ] **Example Create a bucket and specify a canned ACL that grants permission to the S3 log delivery group** This C\$1 example creates a bucket. In the request, the code also specifies a canned ACL that grants the Log Delivery group permissions to write the logs to the bucket. For information about setting up and running the code examples, see [Getting Started with the AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html) in the *AWS SDK for .NET Developer Guide*. ``` using Amazon; using Amazon.S3; using Amazon.S3.Model; using System; using System.Threading.Tasks; namespace Amazon.DocSamples.S3 { class ManagingBucketACLTest { private const string newBucketName = "*** bucket name ***"; // Specify your bucket region (an example region is shown). private static readonly RegionEndpoint bucketRegion = RegionEndpoint.USWest2; private static IAmazonS3 client; public static void Main() { client = new AmazonS3Client(bucketRegion); CreateBucketUseCannedACLAsync().Wait(); } private static async Task CreateBucketUseCannedACLAsync() { try { // Add bucket (specify canned ACL). PutBucketRequest putBucketRequest = new PutBucketRequest() { BucketName = newBucketName, BucketRegion = S3Region.EUW1, // S3Region.US, // Add canned ACL. CannedACL = S3CannedACL.LogDeliveryWrite }; PutBucketResponse putBucketResponse = await client.PutBucketAsync(putBucketRequest); // Retrieve bucket ACL. GetACLResponse getACLResponse = await client.GetACLAsync(new GetACLRequest { BucketName = newBucketName }); } catch (AmazonS3Exception amazonS3Exception) { Console.WriteLine("S3 error occurred. Exception: " + amazonS3Exception.ToString()); } catch (Exception e) { Console.WriteLine("Exception: " + e.ToString()); } } } } ``` **Example Update ACL on an existing object** This C\$1 example updates the ACL on an existing object. The example performs the following tasks: + Retrieves an object's ACL. + Clears the ACL by removing all existing permissions. + Adds two permissions: full access to the owner, and WRITE\$1ACP to a user identified by email address. + Saves the ACL by sending a `PutAcl` request. For information about setting up and running the code examples, see [Getting Started with the AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html) in the *AWS SDK for .NET Developer Guide*. ``` using Amazon; using Amazon.S3; using Amazon.S3.Model; using System; using System.Collections.Generic; using System.Threading.Tasks; namespace Amazon.DocSamples.S3 { class ManagingObjectACLTest { private const string bucketName = "*** bucket name ***"; private const string keyName = "*** object key name ***"; private const string emailAddress = "*** email address ***"; // Specify your bucket region (an example region is shown). private static readonly RegionEndpoint bucketRegion = RegionEndpoint.USWest2; private static IAmazonS3 client; public static void Main() { client = new AmazonS3Client(bucketRegion); TestObjectACLTestAsync().Wait(); } private static async Task TestObjectACLTestAsync() { try { // Retrieve the ACL for the object. GetACLResponse aclResponse = await client.GetACLAsync(new GetACLRequest { BucketName = bucketName, Key = keyName }); S3AccessControlList acl = aclResponse.AccessControlList; // Retrieve the owner (we use this to re-add permissions after we clear the ACL). Owner owner = acl.Owner; // Clear existing grants. acl.Grants.Clear(); // Add a grant to reset the owner's full permission (the previous clear statement removed all permissions). S3Grant fullControlGrant = new S3Grant { Grantee = new S3Grantee { CanonicalUser = owner.Id }, Permission = S3Permission.FULL_CONTROL }; // Describe the grant for the permission using an email address. S3Grant grantUsingEmail = new S3Grant { Grantee = new S3Grantee { EmailAddress = emailAddress }, Permission = S3Permission.WRITE_ACP }; acl.Grants.AddRange(new List { fullControlGrant, grantUsingEmail }); // Set a new ACL. PutACLResponse response = await client.PutACLAsync(new PutACLRequest { BucketName = bucketName, Key = keyName, AccessControlList = acl }); } catch (AmazonS3Exception amazonS3Exception) { Console.WriteLine("An AmazonS3Exception was thrown. Exception: " + amazonS3Exception.ToString()); } catch (Exception e) { Console.WriteLine("Exception: " + e.ToString()); } } } } ``` ------ ## Using the REST API Amazon S3 APIs enable you to set an ACL when you create a bucket or an object. Amazon S3 also provides API to set an ACL on an existing bucket or an object. These APIs provide the following methods to set an ACL: + **Set ACL using request headers—** When you send a request to create a resource (bucket or object), you set an ACL using the request headers. Using these headers, you can either specify a canned ACL or specify grants explicitly (identifying grantee and permissions explicitly). + **Set ACL using request body—** When you send a request to set an ACL on an existing resource, you can set the ACL either in the request header or in the body. For information on the REST API support for managing ACLs, see the following sections in the *Amazon Simple Storage Service API Reference*: + [GetBucketAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETacl.html) + [PutBucketAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTacl.html) + [GetObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGETacl.html) + [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUTacl.html) + [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html) + [CreateBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUT.html) + [CopyObject](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html) + [CreateMultipartUpload](https://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadInitiate.html) **Important** If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set access control lists (ACLs) or update ACLs fail and return the `AccessControlListNotSupported` error code. Requests to read ACLs are still supported. ### Access Control List (ACL)-Specific Request Headers You can use headers to grant access control list (ACL)-based permissions. By default, all objects are private. Only the owner has full access control. When adding a new object, you can grant permissions to individual AWS accounts or to predefined groups defined by Amazon S3. These permissions are then added to the Access Control List (ACL) on the object. For more information, see [Access control list (ACL) overview](acl-overview.md). With this operation, you can grant access permissions using one these two methods: + **Canned ACL (`x-amz-acl`)** — Amazon S3 supports a set of predefined ACLs, known as canned ACLs. Each canned ACL has a predefined set of grantees and permissions. For more information, see [Canned ACL](acl-overview.md#canned-acl). + **Access Permissions** — To explicitly grant access permissions to specific AWS accounts or groups, use the following headers. Each header maps to specific permissions that Amazon S3 supports in an ACL. For more information, see [Access control list (ACL) overview](acl-overview.md). In the header, you specify a list of grantees who get the specific permission. + x-amz-grant-read + x-amz-grant-write + x-amz-grant-read-acp + x-amz-grant-write-acp + x-amz-grant-full-control ## Using the AWS CLI For more information about managing ACLs using the AWS CLI, see [put-bucket-acl](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-acl.html) in the *AWS CLI Command Reference*. **Important** If your general purpose bucket uses the Bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your general purpose bucket and the objects in it. With the Bucket owner enforced setting enabled, requests to set access control lists (ACLs) or update ACLs fail and return the `AccessControlListNotSupported` error code. Requests to read ACLs are still supported. # Policy examples for ACLs You can use condition keys in bucket policies to control access to Amazon S3. **Topics** + [ ## Granting s3:PutObject permission with a condition requiring the bucket owner to get full control ](#grant-putobject-conditionally-1) + [ ## Granting s3:PutObject permission with a condition on the x-amz-acl header ](#example-acl-header) ## Granting s3:PutObject permission with a condition requiring the bucket owner to get full control The [PUT Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html) operation allows access control list (ACL)–specific headers that you can use to grant ACL-based permissions. Using these keys, the bucket owner can set a condition to require specific access permissions when the user uploads an object. Suppose that Account A owns a bucket, and the account administrator wants to grant Dave, a user in Account B, permissions to upload objects. By default, objects that Dave uploads are owned by Account B, and Account A has no permissions on these objects. Because the bucket owner is paying the bills, it wants full permissions on the objects that Dave uploads. The Account A administrator can do this by granting the `s3:PutObject` permission to Dave, with a condition that the request include ACL-specific headers that either grant full permission explicitly or use a canned ACL. For more information, see [PUT Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html). ### Require the x-amz-full-control header You can require the `x-amz-full-control` header in the request with full control permission to the bucket owner. The following bucket policy grants the `s3:PutObject` permission to user Dave with a condition using the `s3:x-amz-grant-full-control` condition key, which requires the request to include the `x-amz-full-control` header. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] } ``` ------ **Note** This example is about cross-account permission. However, if Dave (who is getting the permission) belongs to the AWS account that owns the bucket, this conditional permission is not necessary. This is because the parent account to which Dave belongs owns objects that the user uploads. **Add explicit deny** The preceding bucket policy grants conditional permission to user Dave in Account B. While this policy is in effect, it is possible for Dave to get the same permission without any condition via some other policy. For example, Dave can belong to a group, and you grant the group `s3:PutObject` permission without any condition. To avoid such permission loopholes, you can write a stricter access policy by adding explicit deny. In this example, you explicitly deny the user Dave upload permission if he does not include the necessary headers in the request granting full permissions to the bucket owner. Explicit deny always supersedes any other permission granted. The following is the revised access policy example with explicit deny added. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::111122223333:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringNotEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] } ``` ------ **Test the policy with the AWS CLI** If you have two AWS accounts, you can test the policy using the AWS Command Line Interface (AWS CLI). You attach the policy and use Dave's credentials to test the permission using the following AWS CLI `put-object` command. You provide Dave's credentials by adding the `--profile` parameter. You grant full control permission to the bucket owner by adding the `--grant-full-control` parameter. For more information about setting up and using the AWS CLI, see [Developing with Amazon S3 using the AWS CLI](https://docs.aws.amazon.com/AmazonS3/latest/API/setup-aws-cli.html) in the *Amazon S3 API Reference*. ``` aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID" --profile AccountBUserProfile ``` ### Require the x-amz-acl header You can require the `x-amz-acl` header with a canned ACL granting full control permission to the bucket owner. To require the `x-amz-acl` header in the request, you can replace the key-value pair in the `Condition` block and specify the `s3:x-amz-acl` condition key, as shown in the following example. ``` "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } ``` To test the permission using the AWS CLI, you specify the `--acl` parameter. The AWS CLI then adds the `x-amz-acl` header when it sends the request. ``` aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin ``` ## Granting s3:PutObject permission with a condition on the x-amz-acl header The following bucket policy grants the `s3:PutObject` permission for two AWS accounts if the request includes the `x-amz-acl` header making the object publicly readable. The `Condition` block uses the `StringEquals` condition, and it is provided a key-value pair, `"s3:x-amz-acl":["public-read"]`, for evaluation. In the key-value pair, the `s3:x-amz-acl` is an Amazon S3–specific key, as indicated by the prefix `s3:`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AddCannedAcl", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::111122223333:root" ] }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::awsexamplebucket1/*" ], "Condition": { "StringEquals": { "s3:x-amz-acl": [ "public-read" ] } } } ] } ``` ------ **Important** Not all conditions make sense for all actions. For example, it makes sense to include an `s3:LocationConstraint` condition on a policy that grants the `s3:CreateBucket` Amazon S3 permission. However, it does not make sense to include this condition on a policy that grants the `s3:GetObject` permission. Amazon S3 can test for semantic errors of this type that involve Amazon S3–specific conditions. However, if you are creating a policy for an IAM user or role and you include a semantically invalid Amazon S3 condition, no error is reported because IAM cannot validate Amazon S3 conditions.