[
https://issues.apache.org/jira/browse/HDDS-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jyotinder Singh updated HDDS-6337:
----------------------------------
Description:
If a directory under an FSO bucket does not contain any subfiles/directories -
set the recursive flag for Ranger#getAcl call to false.
h2. Scenario:
*Ranger Policy 1:*
h6. Key Resource - dir1/dir11, dir1/dir11/
h6. Permission - Read, Write, Delete
h6. User - user2
*Ranger Policy 2:*
h6. Key resource - dir*
h6. Permission - Read, Write, Delete
h6. User - user1
*Case:*
1) user2 has created a directory dir1/dir11. Since the explicit policy defined
for user2, it will successfully create the directories.
2) user1 has recursive permission, he can create any dirs under " dir* ". Say,
user1 created a file under directory "dir1/dir11/file".
3) user2 issues recursive delete on "dir1/dir11". {*}(Recursive flag is sent to
Ranger from internal Ozone call){*}.
{code:java}
$ kinit user2
$ ozone fs -rm -R skipTrash o3fs://fso-buycket.vol1.fso-bucket/dir1/dir11{code}
*Expected Result:*
Fail to delete directory.
*Actual Result:*
Permission denied by Ranger.
*Comments:*
* Since there is no permission for user2 with policy key resource dir*, Ranger
is denying permission for users as access is not determined. Ranger has taken a
conservative approach against all the defined policy paths irrespective of the
given user who issues the recursive delete operation.
* Since there is a file under "dir1/dir11", we shouldn't allow this directory
to be deleted, otherwise, this will lead to data loss.
h2. *Impact:*
user2 will never be able to delete "dir1/dir11" since Ozone is always sending
the recursive flag to the Ranger plugin - *which is undesirable.*
h2. *Solution:*
If no child exists under "dir1/dir11" then set the recursive flag to False and
invoke Ranger#checkAcl.
*Cost:*
There will be an additional getChildren call on both DirectoryTable and
FileTable at the Ozone side. Each of these would be a deterministic time call
to RocksDB.
was:
If a directory under an FSO bucket does not contain any subfiles/directories -
set the recursive flag for Ranger#getAcl call to false.
h2. Scenario:
*Ranger Policy 1:*
h6. Key Resource - dir1/dir11, dir1/dir11/
h6. Permission - Read, Write, Delete
h6. User - user2
*Ranger Policy 2:*
h6. Key resource - dir*
h6. Permission - Read, Write, Delete
h6. User - user1
*Case:*
1) user2 has created a directory dir1/dir11. Since the explicit policy defined
for user2, it will successfully create the directories.
2) user1 has recursive permission, he can create any dirs under " dir* ". Say,
user1 created a file under directory "dir1/dir11/file".
3) user2 issues recursive delete on "dir1/dir11". {*}(Recursive flag is sent to
Ranger from internal Ozone call){*}.
{code:java}
$ kinit user2
$ ozone fs -rm -R skipTrash o3fs://fso-buycket.vol1.fso-bucket/dir1/dir11{code}
*Expected Result:*
Fail to delete directory.
*Actual Result:*
Permission denied by Ranger.
*Comments:*
* Since there is no permission for user2 with policy key resource dir*, Ranger
is denying permission for users as access is not determined. Ranger has taken a
conservative approach against all the defined policy paths irrespective of the
given user who issues the recursive delete operation.
* Since there is a file under "dir1/dir11", we shouldn't allow this directory
to be deleted, otherwise, this will lead to data loss.
h2. *Impact:*
- user2 will never be able to delete "dir1/dir11" since Ozone is always sending
the recursive flag to the Ranger plugin - *which is undesirable.*
h2. *Solution:*
If no child exists under "dir1/dir11" then set the recursive flag to False and
invoke Ranger#checkAcl.
*Cost:*
There will be an additional getChildren call on both DirectoryTable and
FileTable at the Ozone side. Each of these would be a deterministic time call
to RocksDB.
> [FSO] Disable recursive access check flag for directories with no children.
> ---------------------------------------------------------------------------
>
> Key: HDDS-6337
> URL: https://issues.apache.org/jira/browse/HDDS-6337
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Jyotinder Singh
> Assignee: Jyotinder Singh
> Priority: Major
>
> If a directory under an FSO bucket does not contain any subfiles/directories
> - set the recursive flag for Ranger#getAcl call to false.
> h2. Scenario:
> *Ranger Policy 1:*
> h6. Key Resource - dir1/dir11, dir1/dir11/
> h6. Permission - Read, Write, Delete
> h6. User - user2
> *Ranger Policy 2:*
> h6. Key resource - dir*
> h6. Permission - Read, Write, Delete
> h6. User - user1
>
> *Case:*
> 1) user2 has created a directory dir1/dir11. Since the explicit policy
> defined for user2, it will successfully create the directories.
> 2) user1 has recursive permission, he can create any dirs under " dir* ".
> Say, user1 created a file under directory "dir1/dir11/file".
> 3) user2 issues recursive delete on "dir1/dir11". {*}(Recursive flag is sent
> to Ranger from internal Ozone call){*}.
>
> {code:java}
> $ kinit user2
> $ ozone fs -rm -R skipTrash
> o3fs://fso-buycket.vol1.fso-bucket/dir1/dir11{code}
>
>
> *Expected Result:*
> Fail to delete directory.
> *Actual Result:*
> Permission denied by Ranger.
>
> *Comments:*
> * Since there is no permission for user2 with policy key resource dir*,
> Ranger is denying permission for users as access is not determined. Ranger
> has taken a conservative approach against all the defined policy paths
> irrespective of the given user who issues the recursive delete operation.
> * Since there is a file under "dir1/dir11", we shouldn't allow this
> directory to be deleted, otherwise, this will lead to data loss.
> h2. *Impact:*
> user2 will never be able to delete "dir1/dir11" since Ozone is always sending
> the recursive flag to the Ranger plugin - *which is undesirable.*
> h2. *Solution:*
> If no child exists under "dir1/dir11" then set the recursive flag to False
> and invoke Ranger#checkAcl.
> *Cost:*
> There will be an additional getChildren call on both DirectoryTable and
> FileTable at the Ozone side. Each of these would be a deterministic time call
> to RocksDB.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
