hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weiwei Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-8312) Trash does not descent into child directories to check for permissions
Date Wed, 17 May 2017 01:13:04 GMT

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

Weiwei Yang commented on HDFS-8312:

Hi [~daryn]

Thank you for sharing your thoughts, I appreciate that.

bq. It's an honor-system based sanity check for the good users. A malicious user is never
going to pass the flag to request the permission subcheck. Why even hack fs -rm to remove
the flag when you can just use fs -mv?

This fix is only fixed the internal code in fs, not exposed this flag to any clients. Because
when trash is enabled, when user runs

{{hdfs dfs -rm /path/to/file}}

at backend, it is implemented by {{rename}} which only checks the privilege to {{rename}}.
This behavior changes semantic under-cover which caused inconsistent behavior with or without
{{-skipTrash}} flag, isn't it? The purpose of the fix is to prevent user to remove files which
they don't have privilege to. More explanation is [here | https://issues.apache.org/jira/browse/HDFS-8312?focusedCommentId=15407456&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15407456].

bq. Consider a *nix system. Let's say I foolishly have a single volume for the entire system,
and I run tmpwatch to delete old stuff in /tmp. It's the same situation. If I have write privs
to a directory, I can move anything in it to /tmp and it'll get blown away.

This is different, user uses {{mv}} to /tmp instead of what trash uses {{rm}}, so they know
what they are doing and it still honors {{mv}} semantic. On the contrary, moving stuff to
trash is using {{rm}} so if it doesn't check {{rm}} privilege seems inconsistent to me.

Please share your ideas if you agree this is a problem that we need to fix. In that case,
if you have a better idea how to fix this, I would love to hear.

Thank you.

> Trash does not descent into child directories to check for permissions
> ----------------------------------------------------------------------
>                 Key: HDFS-8312
>                 URL: https://issues.apache.org/jira/browse/HDFS-8312
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: fs, security
>    Affects Versions: 2.2.0, 2.6.0, 2.7.2
>            Reporter: Eric Yang
>            Assignee: Weiwei Yang
>            Priority: Critical
>             Fix For: 2.9.0, 2.7.4, 3.0.0-alpha1, 2.8.1
>         Attachments: HDFS-8312-001.patch, HDFS-8312-002.patch, HDFS-8312-003.patch, HDFS-8312-004.patch,
HDFS-8312-005.patch, HDFS-8312-branch-2.7.patch, HDFS-8312-branch-2.8.01.patch, HDFS-8312-branch-,
> HDFS trash does not descent into child directory to check if user has permission to delete
files.  For example:
> Run the following command to initialize directory structure as super user:
> {code}
> hadoop fs -mkdir /BSS/level1
> hadoop fs -mkdir /BSS/level1/level2
> hadoop fs -mkdir /BSS/level1/level2/level3
> hadoop fs -put /tmp/appConfig.json /BSS/level1/level2/level3/testfile.txt
> hadoop fs -chown user1:users /BSS/level1/level2/level3/testfile.txt
> hadoop fs -chown -R user1:users /BSS/level1
> hadoop fs -chown -R 750 /BSS/level1
> hadoop fs -chmod -R 640 /BSS/level1/level2/level3/testfile.txt
> hadoop fs -chmod 775 /BSS
> {code}
> Change to a normal user called user2. 
> When trash is enabled:
> {code}
> sudo su user2 -
> hadoop fs -rm -r /BSS/level1
> 15/05/01 16:51:20 INFO fs.TrashPolicyDefault: Namenode trash configuration: Deletion
interval = 3600 minutes, Emptier interval = 0 minutes.
> Moved: 'hdfs://bdvs323.svl.ibm.com:9000/BSS/level1' to trash at: hdfs://bdvs323.svl.ibm.com:9000/user/user2/.Trash/Current
> {code}
> When trash is disabled:
> {code}
> /opt/ibm/biginsights/IHC/bin/hadoop fs -Dfs.trash.interval=0 -rm -r /BSS/level1
> 15/05/01 16:58:31 INFO fs.TrashPolicyDefault: Namenode trash configuration: Deletion
interval = 0 minutes, Emptier interval = 0 minutes.
> rm: Permission denied: user=user2, access=ALL, inode="/BSS/level1":user1:users:drwxr-x---
> {code}
> There is inconsistency between trash behavior and delete behavior.  When trash is enabled,
files owned by user1 is deleted by user2.  It looks like trash does not recursively validate
if the child directory files can be removed.

This message was sent by Atlassian JIRA

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

View raw message