Github user vanzin commented on a diff in the pull request:
https://github.com/apache/spark/pull/20945#discussion_r178991475
--- Diff:
resource-managers/mesos/src/main/scala/org/apache/spark/scheduler/cluster/mesos/MesosClusterScheduler.scala
---
@@ -506,6 +506,10 @@ private[spark] class MesosClusterScheduler(
options ++= Seq("--class", desc.command.mainClass)
}
+ desc.conf.getOption("spark.mesos.proxyUser").foreach { v =>
+ options ++= Seq("--proxy-user", v)
--- End diff --
> If I use client mode and logged in as user X and have a TGT locally then
why is it a security hole?
When the Spark main runs as a different user (proxy user) that user
shouldnt have access to user's X stuff. Is not that true?
No, that is not true. That's why `HiveDelegationTokenProvider` can break
out of the impersonated context, and use the original user to get a delegation
token.
If that code can do it, any code can do it.
Think about it. User X's TGT is written in a file on the local file system.
The file is only readable by user X, so for `spark-submit` to read it, it needs
to run as user X. So, obviously, any code run by `spark-submit` can read that
TGT - including the user code running as the "proxy user", since "proxy user"
is not a concept that applies to the already running process, just how it
authenticates to external services.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
