[
https://issues.apache.org/jira/browse/HDFS-6570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041492#comment-14041492
]
Colin Patrick McCabe commented on HDFS-6570:
--------------------------------------------
bq. Note that the man page for access clearly spells out the risk of
time-of-check/time-of-use race conditions. This API is only going to be useful
for systems implementing their own authorization enforcement on top of HDFS
files, and only if those systems consider the risk acceptable.
Let's make sure that we spell out the risks in the API. In fact, I wonder if
we should we make this {{\@LimitedPrivate}} between Hive and HDFS. The man
page for the {{access}} system call is pretty blunt on my machine: "the use of
this system call should be avoided."
> add api that enables checking if a user has certain permissions on a file
> -------------------------------------------------------------------------
>
> Key: HDFS-6570
> URL: https://issues.apache.org/jira/browse/HDFS-6570
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Thejas M Nair
> Assignee: Chris Nauroth
>
> For some of the authorization modes in Hive, the servers in Hive check if a
> given user has permissions on a certain file or directory. For example, the
> storage based authorization mode allows hive table metadata to be modified
> only when the user has access to the corresponding table directory on hdfs.
> There are likely to be such use cases outside of Hive as well.
> HDFS does not provide an api for such checks. As a result, the logic to check
> if a user has permissions on a directory gets replicated in Hive. This
> results in duplicate logic and there introduces possibilities for
> inconsistencies in the interpretation of the permission model. This becomes a
> bigger problem with the complexity of ACL logic.
> HDFS should provide an api that provides functionality that is similar to
> access function in unistd.h - http://linux.die.net/man/2/access .
--
This message was sent by Atlassian JIRA
(v6.2#6252)
