Tejaskriya commented on code in PR #4938: URL: https://github.com/apache/ozone/pull/4938#discussion_r1247528308
########## hadoop-hdds/docs/content/security/SecurityAcls.md: ########## @@ -78,16 +78,86 @@ allows the user to overwrite an existing ozone key. 6. **Read_ACL** – Allows a user to read the ACL on a specific object. 7. **Write_ACL** – Allows a user to write the ACL on a specific object. -<h3>Ozone Native ACL APIs</h3> +There are 2 types of ACLs based on their scope - **Access** and **Default**.<br> +Access ACLs are limited only to the specific object and not inherited. They control the access to the object itself. +Only Default ACLs support inheritance. This inheritance is limited to only one level. For example, +Any bucket created under a volume which has a Default ACL inherits that Default ACL as an Access ACLs. +The keys added under the bucket do not inherit them. +Default ACLs cannot be set on keys (as there can be no objects under a key). + + +## Ozone Native ACL APIs The ACLs can be manipulated by a set of APIs supported by Ozone. The APIs supported are: 1. **SetAcl** – This API will take user principal, the name, type -of the ozone object and a list of ACLs. + of the ozone object and a list of ACLs. 2. **GetAcl** – This API will take the name and type of the ozone object -and will return a list of ACLs. + and will return a list of ACLs. 3. **AddAcl** - This API will take the name, type of the ozone object, the -ACL, and add it to existing ACL entries of the ozone object. + ACL, and add it to existing ACL entries of the ozone object. 4. **RemoveAcl** - This API will take the name, type of the -ozone object and the ACL that has to be removed. + ozone object and the ACL that has to be removed. + +## ACL Manipulation Using Ozone CLI + +The ACLs can also be manipulated by using the `ozone sh` commands.<br> +Usage: `ozone sh <object> <action> path-to-object [-a <value>]` <br> +`<value>` is of the form `type:name:rights[scope]`.<br> Review Comment: Thank you for the suggestions! I'll look into HDDS-4715 & HDDS-5031 and handle the documentation in a separate PR. Is that okay? ########## hadoop-hdds/docs/content/security/SecurityAcls.md: ########## @@ -78,16 +78,86 @@ allows the user to overwrite an existing ozone key. 6. **Read_ACL** – Allows a user to read the ACL on a specific object. 7. **Write_ACL** – Allows a user to write the ACL on a specific object. -<h3>Ozone Native ACL APIs</h3> +There are 2 types of ACLs based on their scope - **Access** and **Default**.<br> +Access ACLs are limited only to the specific object and not inherited. They control the access to the object itself. +Only Default ACLs support inheritance. This inheritance is limited to only one level. For example, +Any bucket created under a volume which has a Default ACL inherits that Default ACL as an Access ACLs. +The keys added under the bucket do not inherit them. +Default ACLs cannot be set on keys (as there can be no objects under a key). + + +## Ozone Native ACL APIs The ACLs can be manipulated by a set of APIs supported by Ozone. The APIs supported are: 1. **SetAcl** – This API will take user principal, the name, type -of the ozone object and a list of ACLs. + of the ozone object and a list of ACLs. 2. **GetAcl** – This API will take the name and type of the ozone object -and will return a list of ACLs. + and will return a list of ACLs. 3. **AddAcl** - This API will take the name, type of the ozone object, the -ACL, and add it to existing ACL entries of the ozone object. + ACL, and add it to existing ACL entries of the ozone object. 4. **RemoveAcl** - This API will take the name, type of the -ozone object and the ACL that has to be removed. + ozone object and the ACL that has to be removed. + +## ACL Manipulation Using Ozone CLI + +The ACLs can also be manipulated by using the `ozone sh` commands.<br> +Usage: `ozone sh <object> <action> path-to-object [-a <value>]` <br> +`<value>` is of the form `type:name:rights[scope]`.<br> Review Comment: > > `<value>` is of the form `type:name:rights[scope]`. > > I think it's better to call it unity. It's already introduced at the beginning of this document (line 39), as follows: > > ``` > The general format of an ACL is _object_:_who_:_rights_. > > Where an _object_ can be: > > 1. **Volume** - An Ozone volume. e.g. _/volume_ > 2. **Bucket** - An Ozone bucket. e.g. _/volume/bucket_ > 3. **Key** - An object key or an object. e.g. _/volume/bucket/key_ > 4. **Prefix** - A path prefix for a specific key. e.g. _/volume/bucket/prefix1/prefix2_ > ``` I'm sorry, I didn't exactly get what you meant by unity. I've mentioned the format again with the description because it is slightly different from what was mentioned at line 39. Also to specify the legal values for those parameters. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
