Saisai Shao created SPARK-20239:
-----------------------------------
Summary: Improve HistoryServer ACL mechanism
Key: SPARK-20239
URL: https://issues.apache.org/jira/browse/SPARK-20239
Project: Spark
Issue Type: Bug
Components: Spark Core
Affects Versions: 2.2.0
Reporter: Saisai Shao
Current SHS (Spark History Server) two different ACLs.
* ACL of base URL, it is controlled by "spark.acls.enabled" or
"spark.ui.acls.enabled", and with this enabled, only user configured with
"spark.admin.acls" (or group) or "spark.ui.view.acls" (or group), or the user
who started STS could list all the applications, otherwise none of them can be
listed.
* Per application ACL. This is controlled by "spark.history.ui.acls.enabled".
With this enabled only history admin user and user/group for this app when it
was run can access the details of this app.
With this two ACLs, we may encounter several unexpected behaviors:
1. if base URL's ACL is enabled but user A has no view permission. User "A"
cannot see the app list but could access details of it's own app.
2. if ACLs of base URL is disabled. Then user "A" could the summary of all the
apps, even some are not ran by user "A", but cannot access the details.
3. history admin ACL has no permission to list all apps if this admin user is
not added base URL's ACL.
The unexpected behavior of ACLs is mainly because we have two different ACLs,
ideally we should have only one to manage all.
So to improve SHS's ACL mechanism, we should:
* Unify two different ACLs into one, and always honor this (both is base URL
and app details).
* User could partially list and display apps which ran by him according to the
ACLs in event log.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
