whbing commented on code in PR #4938: URL: https://github.com/apache/ozone/pull/4938#discussion_r1235439031
########## 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> +_type_ can be user, group or world.<br> +_name_ is the name of the user/group <br> +_rights_ can be (read=r, write=w, delete-d, list=l, all=a, none=n, create=c, read_acl=x, write_acl=y)<br> Review Comment: `delete-d` -> `delete=d` ########## 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]`.<br> 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_ ``` ########## 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. Review Comment: > This inheritance is limited to only one level This point may be debatable. In the case of FSO or LEGACY (Ignore OBS due to OBS key inherits the DEFAULT ACLs of the bucket): 1. If a bucket has the DEFAULT ACLs, does the ACLs that sub-directory inherited should have DEFAULT scope? 2. Does the sub-directory inherit the DEFAULT ACLs of the bucket or the parent directory? Maybe we can wait for clearing up first. cc @ChenSammi see: HDDS-8653 https://github.com/apache/ozone/discussions/4752 ########## 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: @Tejaskriya Thanks for work on this. I find that this PR is not only about prefix acl, but more like a supplement to acl. Would you consider adding the `acl on link bucket` documentation here as well? see: HDDS-4715. ACL on link bucket HDDS-5031. Documentation: How are ACLs applied w.r.t bucket links Of course, it can also be fixed in HDDS-5031. Thanks ! -- 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]
