ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Madhan Neethiraj (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RANGER-699) higher level policy API to hide complexity of policy update/create/delete
Date Sun, 08 Nov 2015 06:51:10 GMT

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

View raw message