Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 27 Jul 2016 22:07:20 +0000 (UTC)
From: "Chris Nauroth (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12992460.1469499554000.151578.1469657240564@Atlassian.JIRA>
In-Reply-To: <JIRA.12992460.1469499554000@Atlassian.JIRA>
References: <JIRA.12992460.1469499554000@Atlassian.JIRA> <JIRA.12992460.1469499554099@arcas>
Subject: [jira] [Commented] (HDFS-10689) "hdfs dfs -chmod 777" does not
 remove sticky bit
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 27 Jul 2016 22:07:23 -0000


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

Chris Nauroth commented on HDFS-10689:
--------------------------------------

bq. Now the question is if we declare this a bug fix that can be backported to branch-2, or if this behavior change is too incompatible. Given that sticky bits are pretty rare in general, I think it's safe for branch-2, but would welcome other's thoughts. Anything to add Chris Nauroth?

[~andrew.wang], thanks for the notification.  I agree with the proposed change, but the compatibility aspects of changes like this are always tricky to consider.  In this case, the change is something that potentially weakens authorization.  If a user has some automation that runs chmod on a directory, and that user expects the current behavior that sticky bit is preserved, then the effect would be to start allowing users to delete files owned by someone else.  Admittedly, sticky bit usage is rare, typically only on /tmp, but I'd still be more comfortable with this as a 3.x change flagged backward-incompatible.

> "hdfs dfs -chmod 777" does not remove sticky bit
> ------------------------------------------------
>
>                 Key: HDFS-10689
>                 URL: https://issues.apache.org/jira/browse/HDFS-10689
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: fs
>            Reporter: Manoj Govindassamy
>            Assignee: Manoj Govindassamy
>            Priority: Minor
>         Attachments: HDFS-10689.001.patch
>
>
> When a directory permission is modified using hdfs dfs chmod command and when octal/numeric format is used, the leading sticky bit is not fully honored.
> 1. Create a dir dir_test_with_sticky_bit
> 2. Apply sticky bit permission on the dir : hdfs dfs -chmod 1755 /dir_test_with_sticky_bit
> 3. Remove sticky bit permission on the dir: hdfs dfs -chmod 755 /dir_test_with_sticky_bit
> Expected: Remove the sticky bit on the dir, as it happens on Mac/Linux native filesystem with native chmod.
> 4. However, removing sticky bit permission by explicitly turning off the bit works. hdfs dfs -chmod 0755 /dir_test_with_sticky_bit
> {noformat}
> manoj@~/work/hadev-pp: hdfs dfs -chmod 1755 /dir_test_with_sticky_bit
> manoj@~/work/hadev-pp: hdfs dfs -ls /
> Found 2 items
> drwxr-xr-t   - manoj supergroup          0 2016-07-25 11:42 /dir_test_with_sticky_bit
> drwxr-xr-x   - manoj supergroup          0 2016-07-25 11:42 /user
> manoj@~/work/hadev-pp: hdfs dfs -chmod 755 /dir_test_with_sticky_bit
> manoj@~/work/hadev-pp: hdfs dfs -ls /
> Found 2 items
> drwxr-xr-t   - manoj supergroup          0 2016-07-25 11:42 /dir_test_with_sticky_bit  <=== sticky bit still intact
> drwxr-xr-x   - manoj supergroup          0 2016-07-25 11:42 /user
> manoj@~/work/hadev-pp: hdfs dfs -chmod 0755 /dir_test_with_sticky_bit
> manoj@~/work/hadev-pp: hdfs dfs -ls /
> Found 2 items
> drwxr-xr-x   - manoj supergroup          0 2016-07-25 11:42 /dir_test_with_sticky_bit
> drwxr-xr-x   - manoj supergroup          0 2016-07-25 11:42 /user
> manoj@~/work/hadev-pp: 
> {noformat}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org