ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RANGER-699) higher level policy API to hide complexity of policy update/create/delete
Date Thu, 05 Nov 2015 18:49:27 GMT

    [ 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)

Mime
View raw message