[
https://issues.apache.org/jira/browse/RANGER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14981421#comment-14981421
]
Yan commented on RANGER-606:
----------------------------
Balaji, thanks for the clarification. Here are a few observations I'd like to
make, plus a few suggestions and notes.
1) You are right that history (or time-ordering/time-versioning) is not
necessary to resolve conflicts, provided that the conflicts could be avoided at
first place. Policy history could be used for policy traceability and analysis
purposes, but that could be a separate topic in future.
2) At any moment, a specific, outstanding privilege should be unique and keyed
to avoid conflicts. Different privilege models may have diff keys. For HDFS
privilege model, the keys are (path, user/group); while for SQL-type privilege,
the keys are (object, user/group, privilege).
3) DENY would be equivalent to locating one or more policies based upon some
criteria on the key(or part of the key), followed by removing the matched
policy items from the policies. In theory the equivalent steps could be
manually performed. But on a very complex security system in evolution, it
would be a great tool to be had.
Accordingly my suggestions of changes/enhancements are:
1) DENY is to be added, but not as a different type of policy item; but as a
convenience utility and work in the scope of individual repositories.
Specifically, the "Edit Policy" web page will not be changed to add the "DENY
Conditions" as originally purposed. Instead, the repository page, i.e., the
"List of Policies" page, should be enhanced with a "Deny" action based on a
privilege key combination, user/group, and an optional privilege type for
SQL-like resources;
2) For each type of resources, identify the privilege keys, adding the guard in
code against the attempts to create duplicate entries on the keys to guarantee
the privilege uniqueness. For instance, currently for HDFS, path is used as a
key to guarantee the uniqueness between policies. In addition, the user list
too should be checked in each policy to guarantee the uniqueness of the
combinatorial key of (path, user).
Note that, by doing the above,
1) the Range privilege model will very closely match to those of SQL and FS,
both having been well accepted.
2) Minor discrepancies might still exist between different component privilege
models. I suspect (but please correct me if I am wrong here), for instance, the
current Ranger model is recursive in that a privilege to a resource at a higher
level implies the same privilege to a resource at a lower level. This fits SQL
privilege model well, since, for instance, the ability to query a table implies
the same ability to all of the table's columns. But it does not fit HDFS's
privilege model
because FS has separate permissions at each level of a FS directory hierarchy.
Other types of components might fare similarly. If not already, we might need
to add the disparate processing to each component accordingly.
3) The "policy" in Ranger, therefore, will be a privilege grouping/tagging
mechanism for security management purposes.
> 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)
