• Owner

• User by E-mail

• User by Canonical Representation

• AWS User Group

• Anonymous Group

Every bucket and object in Amazon S3 has an owner, the user that created the bucket or object. The owner of a bucket or object cannot be changed. However, if the object is overwritten by another user (deleted and rewritten), the new object will have a new owner.

	Note
	Even the owner is subject to the ACL. For example, if an owner does not have READ access to an object, the owner cannot read that object. However, the owner of an object always has write access to the access control policy (WRITE_ACP) and can change the ACL to read the object.

You can grant access to buckets and objects within your Amazon S3 account to anyone with an Amazon Web Services account. Any users that you grant access will be able to access buckets and objects using their AWS Access Key IDs and Secret Access Keys.

Following is an example that shows the XML format for granting access to a user through an Amazon customer e-mail address.

<Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AmazonCustomerByEmail">
  <EmailAddress>[email protected]</EmailAddress>
</Grantee>

E-mail grants are internally converted to the CanonicalUser representation when you create the ACL. If the grantee changes his or her e-mail address, it will not affect the existing Amazon S3 permissions.

Adding a grantee by e-mail address only works if exactly one Amazon account corresponds to the specified e-mail address. If multiple Amazon accounts are associated with the e-mail address, an AmbiguousGrantByEmail error message is returned. This is rare but usually occurs if a user created an Amazon account in the past, forgot the password, and created another Amazon account using the same e-mail address. If this occurs, the user should contact Amazon.com customer service to have the accounts merged or you should grant user access specifying the CanonicalUser representation.

You can grant access to buckets and objects within your Amazon S3 account to anyone with an Amazon Web Services account. Any users that you grant access will be able to access buckets and objects using their AWS Access Key IDs and Secret Access Keys.

	Note
	To locate the CanonicalUser ID for a user, the user must perform the ListAllMyBuckets operation in his or her Amazon S3 account and copy the ID from the Owner XML object.

Following is an example that example shows the XML format for granting access to a user through an Amazon customer CanonicalUser ID.

<Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
  <ID>a9a7b886d6fd24a52fe8ca5bef65f89a64e0193f23000e241bf9b1c61be666e9</ID>
  <DisplayName>chriscustomer</DisplayName>
</Grantee>

The ID string specifies the CanonicalUser ID and must exactly match the ID of the user that you are adding. The DisplayName element is read-only. If you specify a DisplayName, it will be ignored and replaced with the name stored by Amazon. We recommend that you match your DisplayName to your Forum name.

You can grant access to buckets or objects to anyone with an Amazon AWS account. Although this inherently insecure as any AWS user who is aware of the bucket or object will be able to access it, you might find this authentication method useful.

All AWS users can be specified as a grantee using the following example XML representation.

<Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
  <URI>http://acs.amazonaws.com/groups/global/AuthenticatedUsers<URI>
</Grantee>

You can grant anonymous access to any Amazon S3 object or bucket. Any user will be able to access the object by omitting the AWS Key ID and Signature from a request.

AllUsers can be specified as a grantee using the following example XML representation:

<Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
 <<URI>http://acs.amazonaws.com/groups/global/AllUsers<URI>
</Grantee>

Elements

• READ—when applied to a bucket, grants permission to list the bucket.

  When applied to an object, this grants permission to read the object data and/or metadata.

• WRITE—when applied to a bucket, grants permission to create, overwrite, and delete any object in the bucket.

  This permission is not supported for objects.

• READ_ACP—grants permission to read the ACL for the applicable bucket or object.

  The owner of a bucket or object always has this permission implicitly.

• WRITE_ACP—gives permission to overwrite the ACP for the applicable bucket or object.

  The owner of a bucket or object always has this permission implicitly.

  Granting this permission is equivalent to granting FULL_CONTROL because the grant recipient can make any changes to the ACP.

• FULL_CONTROL—provides READ, WRITE, READ_ACP, and WRITE_ACP permissions.

  It does not convey additional rights and is provided only for convenience.