[
https://issues.apache.org/jira/browse/RANGER-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14992232#comment-14992232
]
Edward Zhang commented on RANGER-699:
-------------------------------------
[~madhan.neethiraj] Thanks for the review. Nice to see that we can generate
resource signature and use that to retrieve existing policies. I will modify
accordingly. But could you please review the following too?
1. For removing user/group from existing policy, as we have
denyPolicyItem,denyException, allowException, so we need iterate all those
policyItem set right?
2. For removing user/group from existing policy, after we remove, we should add
it back right.
for(RangerPolicyItem newItem : policy.getPolicyItems()){
removePolicyItemInPlace(newItem,
existingPolicy.getDenyPolicyItems());
removePolicyItemInPlace(newItem,
existingPolicy.getAllowExceptions());
addPolicyItemInPlace(newItem,
existingPolicy.getPolicyItems());
}
for(RangerPolicyItem newItem : policy.getDenyPolicyItems()){
removePolicyItemInPlace(newItem,
existingPolicy.getPolicyItems());
removePolicyItemInPlace(newItem,
existingPolicy.getDenyExceptions());
addPolicyItemInPlace(newItem,
existingPolicy.getDenyPolicyItems());
}
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.
private void removePolicyItemInPlace(RangerPolicyItem toBeRemoved,
List<RangerPolicyItem> existingPolicyItems){
Iterator<RangerPolicyItem> iter =
existingPolicyItems.iterator();
while(iter.hasNext()){
RangerPolicyItem existingItem = iter.next();
if(CollectionUtils.intersection(existingItem.getUsers(),
toBeRemoved.getUsers()).size() > 0 ||
CollectionUtils.intersection(existingItem.getGroups(),
toBeRemoved.getGroups()).size() > 0){
if(!CollectionUtils.isEqualCollection(existingItem.getAccesses(),
toBeRemoved.getAccesses()))
throw new
IllegalStateException("policy deny/allow flip should happen to exactly same
access methods");
existingItem.getUsers().removeAll(toBeRemoved.getUsers());
existingItem.getGroups().removeAll(toBeRemoved.getGroups());
if(existingItem.getUsers().isEmpty() &&
existingItem.getGroups().isEmpty()){
iter.remove();
}
}
}
}
> 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)
