[
https://issues.apache.org/jira/browse/RANGER-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14995541#comment-14995541
]
Madhan Neethiraj commented on RANGER-699:
-----------------------------------------
bq. 1. For removing user/group from existing policy, as we have
denyPolicyItem,denyException, allowException, so we need iterate all those
policyItem set right?
Each list of policyItems in an existing policy (policyItems, denyPolicyItems,
allowExceptions, denyExceptions) should be updated with the content of the
corresponding list given in the method parameter. Removing of users/groups
should be done when accessTypes in the policy item is empty. So if the
denyPolicyItems in the given policy has a policyItem with user1 but with no
accessTypes, then all entries denyPolicyItems in the existing policy must be
updated to remove references to user1. Similarly if the policyItems in the
given policy has a policyItem with user1 but with no accessTypes, then all
entries in "policyItems" should be updated to remove referenced to user1.
bq. 2. For removing user/group from existing policy, after we remove, we should
add it back right.
I am not sure why the users/groups removed from the existing policy would be
added back. Wouldn't this effectively result in no updates to the existing
policy?
bq. 3. when we remove a policy item, do we need check if the same user has the
same accesses in existing policy? If we don't check, we probably remove more
privileges than we expect.
A policyItem should be removed only when the given policy (as a method
parameter) has empty list of accessTypes. If the accessType is not empty, then
accessTypes that are not in the given policyItem should be removed from the
existing policyItem. The result should be that the user will have only the
accesses specified in the policy given in the method parameter.
> higher level policy API to hide complexity of policy update/create/delete
> -------------------------------------------------------------------------
>
> Key: RANGER-699
> URL: https://issues.apache.org/jira/browse/RANGER-699
> Project: Ranger
> Issue Type: Improvement
> Components: admin
> Affects Versions: 0.6.0
> Reporter: Edward Zhang
> Assignee: Edward Zhang
> Fix For: 0.6.0
>
> Original Estimate: 720h
> Remaining Estimate: 720h
>
> Ranger has very good fine-grained policy API with which user can define
> access control rules for any resource. But sometimes it is not human being
> but third party tools may use Ranger policy API to temporarily block or
> unblock user. The third party tool just wants to simply tell Ranger that
> "please block/unblock this user from accessing resource A" and the third
> party tool is not able to analyze the complicated scenarios as follows:
> 1. The exactly same rule already exists for resource A
> 2. The current rules for resource A includes the new rule implicitly
> 3. There is no any rules for resource A
> If it's admin to operate the policy, admin can analyze policy semantics and
> will figure out it's to create a new policy or update an existing policy.
> To better support integration from third party tool, Ranger can provide a
> higher level API which accepts request like "block user access to one
> resource" and internally figure out what policy to create/update.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
