[
https://issues.apache.org/jira/browse/RANGER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979203#comment-14979203
]
Yan commented on RANGER-606:
----------------------------
[~madhan.neethiraj] Thanks for the explanation and the example use case.
To resolve the mentioned difficulty of the example, there are two alternative
approaches.
The first is to clearly define the semantics of saving a policy. That is, a
(time-ordered) policy is an atomic body whose component “policy items”, once
saved, are atomically committed as a whole. So the security admin needs to be
aware of the consequences of saving a potentially outdated policy again after
updating. Or he can just use a separate policy. Or even the “overwriting”
effect is probably what he has hoped for to, say, reestablish an older policy.
The second and more delicate approach is to timestamp the individual “policy
items” so that only the newest items are timestamped and saved. This approach
essentially will treat the policy as a grouping/tagging mechanism for the
policy items for management purposes.
In summary, the difficulty of the example use case seems to be actually a
question of scoping/granularity of policies and/or the commit semantics of
them. It does not mean new privilege conflicts introduced by the time-ordering.
Basically over time security systems will evolve and may well become quite
complex and harder to grasp from the top of head. Validation may well be
necessary. Conflicts may well appear and ideally should be resolved as much as
possible.
Time-stamped/versioned policies also carry an advantage of good traceability
and allow for powerful analysis on the policies and their evolutions, which
could well be another added value compared with component, native systems.
Lastly, there might be a subtle difference between "allow/deny" and
"grant/revoke". DENY might mean a "hard" refusal so that privileges are removed
outright and without considerations of other factors such as on hierarchal
resources or by a hierarchal entity(users and groups) if such conflicts were
to be resolved in a permissive manner. So maybe "Grant/Revoke" are better terms
than "Allow/Deny" given the current permissive resolution of conflicts.
> Add support for deny policies
> ------------------------------
>
> Key: RANGER-606
> URL: https://issues.apache.org/jira/browse/RANGER-606
> Project: Ranger
> Issue Type: Bug
> Components: admin, plugins
> Affects Versions: 0.5.0
> Reporter: Madhan Neethiraj
> Assignee: Madhan Neethiraj
> Fix For: 0.5.0
>
>
> Currently Ranger supports creation of policies that can allow access when
> specific conditions are met (for example, resources, user, groups,
> access-type, custom-conditions..). In addition to this, having the ability to
> create policies that deny access for specific conditions will help address
> many usecases, like:
> - deny access for specific users/groups/ip-addresses/time-of-day
> - deny access when specific conditions are met - like
> resources/users/groups/access-types/custom-conditions
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
