[ https://issues.apache.org/jira/browse/HDFS-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706498#comment-13706498 ]
Hadoop QA commented on HDFS-4968: --------------------------------- {color:red}-1 overall{color}. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12591917/hdfs-4968-1.patch against trunk revision . {color:green}+1 @author{color}. The patch does not contain any @author tags. {color:green}+1 tests included{color}. The patch appears to include 1 new or modified test files. {color:green}+1 javac{color}. The applied patch does not increase the total number of javac compiler warnings. {color:green}+1 javadoc{color}. The javadoc tool did not generate any warning messages. {color:red}-1 eclipse:eclipse{color}. The patch failed to build with eclipse:eclipse. {color:green}+1 findbugs{color}. The patch does not introduce any new Findbugs (version 1.3.9) warnings. {color:red}-1 release audit{color}. The applied patch generated 1 release audit warnings. {color:green}+1 core tests{color}. The patch passed unit tests in hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs. {color:green}+1 contrib tests{color}. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/4636//testReport/ Release audit warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/4636//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/4636//console This message is automatically generated. > Provide configuration option for FileSystem symlink resolution > -------------------------------------------------------------- > > Key: HDFS-4968 > URL: https://issues.apache.org/jira/browse/HDFS-4968 > Project: Hadoop HDFS > Issue Type: Improvement > Affects Versions: 3.0.0, 2.2.0 > Reporter: Andrew Wang > Assignee: Andrew Wang > Attachments: hdfs-4968-1.patch > > > With FileSystem symlink support incoming in HADOOP-8040, some clients will > wish to not transparently resolve symlinks. This is somewhat similar to > O_NOFOLLOW in open(2). > Rationale for is for a security model where a user can invoke a third-party > service running as a service user to operate on the user's data. For > instance, users might want to use Hive to query data in their homedirs, where > Hive runs as the Hive user and the data is readable by the Hive user. This > leads to a security issue with symlinks: > # User Mallory invokes Hive to process data files in {{/user/mallory/hive/}} > # Hive checks permissions on the files in {{/user/mallory/hive/}} and allows > the query to proceed. > # RACE: Mallory replaces the files in {{/user/mallory/hive}} with symlinks > that point to user Ann's Hive files in {{/user/ann/hive}}. These files aren't > readable by Mallory, but she can create whatever symlinks she wants in her > own scratch directory. > # Hive's MR jobs happily resolve the symlinks and accesses Ann's private data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira