Github user tgravescs commented on a diff in the pull request:
https://github.com/apache/spark/pull/509#discussion_r11917289
--- Diff: core/src/main/scala/org/apache/spark/SecurityManager.scala ---
@@ -139,13 +139,13 @@ private[spark] class SecurityManager(sparkConf:
SparkConf) extends Logging {
private val sparkSecretLookupKey = "sparkCookie"
private val authOn = sparkConf.getBoolean("spark.authenticate", false)
- private val uiAclsOn = sparkConf.getBoolean("spark.ui.acls.enable",
false)
+ private var uiAclsOn = sparkConf.getBoolean("spark.ui.acls.enable",
false)
--- End diff --
I think you are mistaken. Unless I'm missing a bug in the code.
The user can't call and shouldn't call setUIAcls... its private. The only
reason it was added was for the history server to call it. Honestly not fond
of having it at all but it was the only way to make the history server work
without major rework. The UI does always honor the spark.ui.acls.enable (or
setUIAcls which is set to whatever the application has set for
spark.ui.acls.enable from the history log).
spark.ui.acls.enable is controlled at the application level and is always
honored at the application level. The history server does not override it. I
put a comment in the code in HistoryServer.scala that says we could do that if
we chose. That is actually how the mapreduce job history server works. That
allows admins to have more control over it and doesn't rely on the user to do
the right thing. if the history server ui.acls.enable setting is true then its
enforces acls across all applications no matter what the application set it to.
I chose not to implement it that way though
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
