[
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-2.8.1.001.patch, HDFS-8312-testcase.patch
>
>
> 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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
