[
https://issues.apache.org/jira/browse/RANGER-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696626#comment-14696626
]
Alok Lal commented on RANGER-612:
---------------------------------
{quote}
This applies with the introduction of Tag based policies, where if there is an
explicit allow to users and groups for the tag. And if any users/groups are not
allowed in that policy, then Ranger shouldn't fallback to HDFS native
permissions, but straight out deny the request.
{quote}
Is _explicit Allow_ the same as DENY_OTHERS policy?
{quote}
This makes sense, because the admin's intention here is to block (or give
explicit permissions) to certain users for the resource. When the intention is
explicit, then all other policies including from HDFS native permissions
shouldn't be considered.
{quote}
Is it possible that admin would create ranger policies as an exception, i.e.
grant permissions to those users who would otherwise be denied access due to
access permissions at HDFS level. Since we have had HDFS fallback for a while,
is it possible that admin's were relying on the fallback and use Ranger
policies to manage exceptions instead?
> Update HDFS plugin to fallback to hadoop-acl only when there is no Ranger
> policy to determine the authorization
> ---------------------------------------------------------------------------------------------------------------
>
> Key: RANGER-612
> URL: https://issues.apache.org/jira/browse/RANGER-612
> Project: Ranger
> Issue Type: Sub-task
> Components: plugins
> Affects Versions: 0.5.0
> Reporter: Madhan Neethiraj
> Assignee: Madhan Neethiraj
> Fix For: 0.5.0
>
>
> Currently (ranger-0.5), Ranger HDFS plugin does a fallback to hadoop-acl when
> Ranger policies do not allow the requested access. This should be updated to
> fallback only when Ranger policies do not determine the authorization i.e.
> there is no Ranger policy to either ALLOW or DENY the access. This fix is
> required to support scenarios where Ranger policies can DENY the access.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
