Return-Path: X-Original-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7D99C10D83 for ; Fri, 12 Jul 2013 04:39:53 +0000 (UTC) Received: (qmail 70203 invoked by uid 500); 12 Jul 2013 04:39:51 -0000 Delivered-To: apmail-hadoop-hdfs-issues-archive@hadoop.apache.org Received: (qmail 70103 invoked by uid 500); 12 Jul 2013 04:39:51 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-issues@hadoop.apache.org Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 70084 invoked by uid 99); 12 Jul 2013 04:39:51 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jul 2013 04:39:51 +0000 Date: Fri, 12 Jul 2013 04:39:50 +0000 (UTC) From: "Andrew Wang (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HDFS-4968) Provide configuration option for FileSystem symlink resolution MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HDFS-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Wang updated HDFS-4968: ------------------------------ Attachment: hdfs-4968-1.patch Reattaching the same patch, I think the release warning is spurious based on the mailing list. mvn eclipse:eclipse also works fine for me locally, not sure what's up with that. > 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