Configuring ACLs for Existing Resources
The OBS allows you to set an ACL for an existing bucket or object. After the ACL is configured successfully, the previous ACL will be overwritten and the new ACL takes effect. The ACL format of an existing resource is XML. The format is as follows:
- Setting the ACL Format for an Existing Bucket
<AccessControlPolicy> <Owner> <ID>domainId</ID> </Owner> <AccessControlList> <Grant> <Grantee> <ID>domainId</ID> </Grantee> <Grant> </AccessControlPolicy>
Delivered in Grant indicates whether the ACL permission of the bucket is passed to the object in the bucket. If the value is true, the ACL permissions of the object are the same as the ACL permissions of the bucket unless the object displays that the ACL permissions of the bucket is not inherited.
- Setting the ACL Format for an Existing Object
<AccessControlPolicy> <Owner> <ID>domainId</ID> </Owner> <Delivered>true</Delivered> <AccessControlList> <Grant> <Grantee> <ID>domainId</ID> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> </AccessControlList> </AccessControlPolicy>
Delivered in the ACL list indicates whether the object ACL inherits the ACL permission of the bucket. The default value is true. The object inherits the bucket ACL permissions by default. If you do not want to inherit the bucket ACL permissions, set this parameter to false.
The ACL check for buckets is simple, but complex for object. Therefore, Delivered needs to be considered. Check the object ACL. If the ACL permission of the object does not meet the requirement and is <Delivered>true</Delivered>, continue to check the bucket ACL. If the ACL permission of the bucket is <Delivered>true</Delivered>, the ACL can be applied to the object. If the object ACL is configured to <Delivered>false</Delivered>, the ACL permission of the bucket cannot be inherited. If the ACL permission of the bucket is <Delivered>false</Delivered>, the bucket permission cannot be applied to the object. (The permission inheritance must be the <Delivered>true</Delivered> of the object, and the permission of the bucket is <Delivered>true</Delivered>.)
OBS supports five types of permissions (for details, see Table 1). <Grantee> indicates the target of permission granting, including OBS users and all users. The format of permission is slightly different.
- Grantee is an OBS user:
<Grantee> <ID>domainId</ID> </Grantee>
- Grantee is everyone:
<Grantee> <Canned>Everyone</Canned> </Grantee>
|
Permission |
Description |
|---|---|
|
READ |
If you have the read permission for a bucket, you can obtain the list of objects, multipart tasks, and multiple object versions in the bucket, as well as metadata of the bucket. A grantee with such a permission for an object can obtain the object content and metadata. |
|
WRITE |
A grantee with such a permission on a bucket can upload, overwrite, and delete any object or part in the bucket. This permission is not applicable to objects. |
|
READ_ACP |
A grantee with this permission can obtain the ACL of a bucket or object. A bucket or object owner has this permission permanently. |
|
WRITE_ACP |
A grantee with this permission can update the ACL of a bucket or object. A bucket or object owner has this permission permanently. A grantee with such a permission can modify the access control policy to obtain desired access permission. |
|
FULL_CONTROL |
A grantee with such a permission for a bucket has READ, WRITE, READ_ACP, and WRITE_ACP permissions. A grantee with such a permission for an object has READ, READ_ACP, and WRITE_ACP permissions. This restriction does not apply to users with the read-only permission. |
A request supports a maximum of 100 permissions.
Instead of being added with new permissions, the ACL of a bucket or object is overwritten after a grant of permissions for the bucket or object is performed.
Last Article: Introduction to the ACL
Next Article: Configuring an ACL Using Header Fields
Did this article solve your problem?
Thank you for your score!Your feedback would help us improve the website.