[
https://issues.apache.org/jira/browse/HADOOP-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16607365#comment-16607365
]
Eric Yang commented on HADOOP-15725:
------------------------------------
[~oshevchenko] Thank you for the example, and I confirmed that if the program
is running as root user, and HDFS is also running as root user. The delete
call will carry out. If the java code is running as a different user than hdfs
super user, then the file doesn't get deleted. It does look like a bug that
using super user to impersonate a less privileged user to perform operation,
and the operation still carry out with super user privilege is a concerning
problem and needs to be addressed. Both secure and insecure cluster seems to
have the same bug that super user impersonate a lesser privileged user doesn't
prevent invocation of super user power.
You are correct that this is not acceptable for insecure cluster as well.
Before this bug is fixed, the rule of thumb is to prevent running program with
hdfs super user. It is too mighty powerful. At least, kerberos enabled
cluster, user must have login to KDC with hdfs super user to exploit this bug.
It is not easily carry out by unauthorized user.
> FileSystem.deleteOnExit should check user permissions
> -----------------------------------------------------
>
> Key: HADOOP-15725
> URL: https://issues.apache.org/jira/browse/HADOOP-15725
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Oleksandr Shevchenko
> Priority: Major
> Labels: Security
> Attachments: deleteOnExitReproduce
>
>
> For now, we able to add any file to FileSystem deleteOnExit list. It leads to
> security problems. Some user (Intruder) can get file system instance which
> was created by another user (Owner) and mark any files to delete even if
> "Intruder" doesn't have any access to this files. Later when "Owner" invoke
> close method (or JVM is shut down since we have ShutdownHook which able to
> close all file systems) marked files will be deleted successfully since
> deleting was do behalf of "Owner" (or behalf of a user who ran a program).
> I attached the patch [^deleteOnExitReproduce] which reproduces this
> possibility and also I able to reproduce it on a cluster with both Local and
> Distributed file systems:
> {code:java}
> public class Main {
> public static void main(String[] args) throws Exception {
> final FileSystem fs;
> Configuration conf = new Configuration();
> conf.set("fs.default.name", "hdfs://node:9000");
> conf.set("fs.hdfs.impl",
> org.apache.hadoop.hdfs.DistributedFileSystem.class.getName()
> );
> fs = FileSystem.get(conf);
> System.out.println(fs);
> Path f = new Path("/user/root/testfile");
> System.out.println(f);
> UserGroupInformation hive = UserGroupInformation.createRemoteUser("hive");
> hive.doAs((PrivilegedExceptionAction<Boolean>) () -> fs.deleteOnExit(f));
> fs.close();
> }
> {code}
> Result:
> {noformat}
> root@node:/# hadoop fs -put testfile /user/root
> root@node:/# hadoop fs -chmod 700 /user/root/testfile
> root@node:/# hadoop fs -ls /user/root
> Found 1 items
> -rw------- 1 root supergroup 0 2018-09-06 18:07 /user/root/testfile
> root@node:/# java -jar testDeleteOther.jar
> log4j:WARN No appenders could be found for logger
> (org.apache.hadoop.conf.Configuration.deprecation).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info.
> DFS[DFSClient[clientName=DFSClient_NONMAPREDUCE_309539034_1, ugi=root
> (auth:SIMPLE)]]
> /user/root/testfile
> []
> root@node:/# hadoop fs -ls /user/root
> root@node:/#
> {noformat}
> We should add a check user permissions before mark a file to delete.
> Could someone evaluate this? And if no one objects I would like to start
> working on this.
> Thanks a lot for any comments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
