[ https://issues.apache.org/jira/browse/HIVE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384753#comment-14384753 ]
Pankit Thapar commented on HIVE-10022: -------------------------------------- Hi [~thejas] , Can you please comment on the failures. These tests pass on my local machine. Only testNegativeCliDriver_authorization_uri_import fails but that fails even without the patch on my local machine. > DFS in authorization might take too long > ---------------------------------------- > > Key: HIVE-10022 > URL: https://issues.apache.org/jira/browse/HIVE-10022 > Project: Hive > Issue Type: Bug > Components: Authorization > Affects Versions: 0.14.0 > Reporter: Pankit Thapar > Assignee: Pankit Thapar > Fix For: 1.0.1 > > Attachments: HIVE-10022.2.patch, HIVE-10022.patch > > > I am testing a query like : > set hive.test.authz.sstd.hs2.mode=true; > set > hive.security.authorization.manager=org.apache.hadoop.hive.ql.security.authorization.plugin.sqlstd.SQLStdHiveAuthorizerFactoryForTest; > set > hive.security.authenticator.manager=org.apache.hadoop.hive.ql.security.SessionStateConfigUserAuthenticator; > set hive.security.authorization.enabled=true; > set user.name=user1; > create table auth_noupd(i int) clustered by (i) into 2 buckets stored as orc > location '${OUTPUT}' TBLPROPERTIES ('transactional'='true'); > Now, in the above query, since authorization is true, > we would end up calling doAuthorizationV2() which ultimately ends up calling > SQLAuthorizationUtils.getPrivilegesFromFS() which calls a recursive method : > FileUtils.isActionPermittedForFileHierarchy() with the object or the ancestor > of the object we are trying to authorize if the object does not exist. > The logic in FileUtils.isActionPermittedForFileHierarchy() is DFS. > Now assume, we have a path as a/b/c/d that we are trying to authorize. > In case, a/b/c/d does not exist, we would call > FileUtils.isActionPermittedForFileHierarchy() with say a/b/ assuming a/b/c > also does not exist. > If under the subtree at a/b, we have millions of files, then > FileUtils.isActionPermittedForFileHierarchy() is going to check file > permission on each of those objects. > I do not completely understand why do we have to check for file permissions > in all the objects in branch of the tree that we are not trying to read > from /write to. > We could have checked file permission on the ancestor that exists and if it > matches what we expect, the return true. > Please confirm if this is a bug so that I can submit a patch else let me know > what I am missing ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)