hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6570) add api that enables checking if a user has certain permissions on a file
Date Sat, 26 Jul 2014 14:20:39 GMT

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

Chris Nauroth commented on HDFS-6570:
-------------------------------------

Sorry, Jitendra.  I just realized there is one more small problem in {{FSNamesystem#checkAccess}}.
 Take a look at HDFS-6749.  We just fixed a bug where a few {{FSNamesystem}} methods were
not calling {{resolvePath}}, and I can see that our new {{checkAccess}} method in this patch
has the same problem.  The fix will look similar to the change applied to {{getAclStatus}}
in HDFS-6749.  It's just adding 2 lines to call {{FSDirectory#getPathComponentsForReservedPath}}
and {{FSDirectory#resolvePath}}:

{code}
@@ -8183,9 +8185,11 @@ AclStatus getAclStatus(String src) throws IOException {
     nnConf.checkAclsConfigFlag();
     FSPermissionChecker pc = getPermissionChecker();
     checkOperation(OperationCategory.READ);
+    byte[][] pathComponents = FSDirectory.getPathComponentsForReservedPath(src);
     readLock();
     try {
       checkOperation(OperationCategory.READ);
+      src = FSDirectory.resolvePath(src, pathComponents, dir);
       if (isPermissionEnabled) {
         checkPermission(pc, src, false, null, null, null, null);
       }
{code}

Then, for testing, we can just add a line here to {{TestINodeFile}} to call {{fs.access(testFileInodePath);}}:

{code}
+
+      /*
+       * HDFS-6749 added missing calls to FSDirectory.resolvePath in the
+       * following four methods. The calls below ensure that
+       * /.reserved/.inodes paths work properly. No need to check return
+       * values as these methods are tested elsewhere.
+       */
+      {
+        fs.isFileClosed(testFileInodePath);
+        fs.getAclStatus(testFileInodePath);
+        fs.getXAttrs(testFileInodePath);
+        fs.listXAttrs(testFileInodePath);
+      }
{code}

I suspect the test would fail before making the change in {{FSNamesystem}} and then pass after
you make the change.

+1 after that very minor change.  Thanks very much!

> 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
>          Components: hdfs-client, namenode, webhdfs
>            Reporter: Thejas M Nair
>            Assignee: Jitendra Nath Pandey
>         Attachments: HDFS-6570-prototype.1.patch, HDFS-6570.2.patch, HDFS-6570.3.patch,
HDFS-6570.4.patch
>
>
> 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)

Mime
View raw message