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