[
https://issues.apache.org/jira/browse/HADOOP-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13726324#comment-13726324
]
Hudson commented on HADOOP-9758:
--------------------------------
SUCCESS: Integrated in Hadoop-Yarn-trunk #288 (See
[https://builds.apache.org/job/Hadoop-Yarn-trunk/288/])
HADOOP-9758. Provide configuration option for FS/FC symlink resolution.
(Andrew Wang via Colin Patrick McCabe) (cmccabe:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1509064)
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/CommonConfigurationKeysPublic.java
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FSLinkResolver.java
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileContext.java
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystemLinkResolver.java
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/resources/core-default.xml
*
/hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/fs/TestSymlinkHdfsDisable.java
> Provide configuration option for FileSystem/FileContext symlink resolution
> --------------------------------------------------------------------------
>
> Key: HADOOP-9758
> URL: https://issues.apache.org/jira/browse/HADOOP-9758
> Project: Hadoop Common
> Issue Type: Improvement
> Affects Versions: 3.0.0, 2.3.0
> Reporter: Andrew Wang
> Assignee: Andrew Wang
> Fix For: 2.3.0
>
> Attachments: hadoop-9758-4.patch, hadoop-9758-5.patch,
> hadoop-9758-6.patch, hdfs-4968-1.patch, hdfs-4968-2.patch, hdfs-4968-3.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 is also potentially useful for clients using FileContext, so let's add
> it there too.
--
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
