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] [Comment Edited] (RANGER-608) Denied access to list a directory does not generate audit
Date Wed, 04 Nov 2015 22:38:27 GMT

    [ https://issues.apache.org/jira/browse/RANGER-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14990591#comment-14990591
] 

Madhan Neethiraj edited comment on RANGER-608 at 11/4/15 10:38 PM:
-------------------------------------------------------------------

HDFS pluggable authorizer, introduced in ranger-0.5 timeframe, calls the authorizer twice
before allowing access to the requested file or directory. 
 - #1: checkPermission() is called with no access to check for on the target file/directory.
In this case, the Ranger authorizer checks if Ranger policies can determine traverse (EXECUTE)
access to the target file/directory for the user. If no Ranger policy exists to determine
this access, the default authorizer (HDFS ACL) is asked to authorizer the access. HDFS default
authorizer checks if user has traverse access (EXECUTE) to the parent and ancestor nodes in
the tree.
- #2: checkPermission() is called again only when the first call succeeds (i.e. EXECUTE access
was allowed), On the second time, checkPermission() is called to check if the desired access
(READ/WRITE/READ_EXECUTE/..) is allowed on the target file/directory. Just like in the first
call, if no Ranger policy exists to determine this access, the default authorizer (HDFS ACL)
is asked to authorizer the access.

To avoid generating 2 audit logs for each access to a file/directory, Ranger plugin does not
generate audit logs in call #1 (i.e. when it was called with no access to check for). This
resulted in no audit logs getting generated when access was not allowed by call #1.

I am working on a fix to this issue and will upload shortly for review.


was (Author: madhan.neethiraj):
HDFS pluggable authorizer, introduced in ranger-0.5 timeframe, calls the authorizer twice
before allowing access to the requested file or directory. 
 - #1: checkPermission() is called with no access to check for on the target file/directory.
In this case, the Ranger authorizer checks if Ranger policies can determine traverse (EXECUTE)
access to the target file/directory for the user. If no Ranger policy exists to determine
this access, the default authorizer (HDFS ACL) is asked to authorizer the access. HDFS default
authorizer checks if user has traverse access (EXECUTE) to the parent and ancestor nodes in
the tree.
- #2: checkPermission() is called again only when the first call succeeds (i.e. EXECUTE access
was allowed), On the second time, checkPermission() is called to check if the desired access
(READ/WRITE/READ_EXECUTE/..) is allowed on the target file/directory. Just like in the first
call, if no Ranger policy exists to determine this access, the default authorizer (HDFS ACL)
is asked to authorizer the access.

To avoid generating 2 audit logs for a single access to a file/directory, Ranger plugin does
not generate audit logs in call #1 (i.e. when it was called with no access to check for).
This resulted in no audit logs getting generated when access is not allowed by Call #1.

I am working on a fix to this issue and will upload shortly for review.

> Denied access to list a directory does not generate audit
> ---------------------------------------------------------
>
>                 Key: RANGER-608
>                 URL: https://issues.apache.org/jira/browse/RANGER-608
>             Project: Ranger
>          Issue Type: Bug
>          Components: plugins
>    Affects Versions: 0.5.0
>            Reporter: Madhan Neethiraj
>            Assignee: Madhan Neethiraj
>
> Attempting to list a directory (for example, /demo/data/Customers) on which the user
does not have READ and EXECUTE access fails with 'Permission denied' error - as expected.
Ranger HDFS plugin generates an audit log for access to HDFS files/directories - irrespective
of whether the access is allowed or denied. However, if the user does not have EXECUTE access
on the parent directory (for example, /demo/data), no audit log is generated for the denial.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message