[
https://issues.apache.org/jira/browse/SPARK-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saisai Shao updated SPARK-20239:
--------------------------------
Description:
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 SHS could list all the applications, otherwise none of them can be
listed. This will also affect REST APIs which listing the summary of all apps
and one app.
* Per application ACL. This is controlled by "spark.history.ui.acls.enabled".
With this enabled only history admin user and user/group who ran this app 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 still access details of it's own app.
2. if ACLs of base URL is disabled. Then user "A" could see the summary of all
the apps, even some didn't run 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 to base URL's ACL.
The unexpected behaviors 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 one (both in base
URL and app details).
* User could partially list and display apps which ran by him according to the
ACLs in event log.
was:
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.
> 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 SHS could list all the applications, otherwise none of them can
> be listed. This will also affect REST APIs which listing the summary of all
> apps and one app.
> * Per application ACL. This is controlled by "spark.history.ui.acls.enabled".
> With this enabled only history admin user and user/group who ran this app 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 still access details of it's own app.
> 2. if ACLs of base URL is disabled. Then user "A" could see the summary of
> all the apps, even some didn't run 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 to base URL's ACL.
> The unexpected behaviors 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 one (both in 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]
