You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Thomas Graves (JIRA)" <ji...@apache.org> on 2017/01/06 16:09:58 UTC

[jira] [Resolved] (SPARK-19033) HistoryServer still uses old ACLs even if ACLs are updated

     [ https://issues.apache.org/jira/browse/SPARK-19033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Graves resolved SPARK-19033.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: 2.2.0
                   2.1.1

> HistoryServer still uses old ACLs even if ACLs are updated
> ----------------------------------------------------------
>
>                 Key: SPARK-19033
>                 URL: https://issues.apache.org/jira/browse/SPARK-19033
>             Project: Spark
>          Issue Type: Bug
>          Components: Spark Core
>    Affects Versions: 2.1.0
>            Reporter: Saisai Shao
>            Assignee: Saisai Shao
>            Priority: Minor
>             Fix For: 2.1.1, 2.2.0
>
>
> In the current implementation of HistoryServer, Application ACLs is picked from event log rather than configuration:
> {code}
>             val uiAclsEnabled = conf.getBoolean("spark.history.ui.acls.enable", false)
>             ui.getSecurityManager.setAcls(uiAclsEnabled)
>             // make sure to set admin acls before view acls so they are properly picked up
>             ui.getSecurityManager.setAdminAcls(appListener.adminAcls.getOrElse(""))
>             ui.getSecurityManager.setViewAcls(attempt.sparkUser,
>               appListener.viewAcls.getOrElse(""))
>             ui.getSecurityManager.setAdminAclsGroups(appListener.adminAclsGroups.getOrElse(""))
>             ui.getSecurityManager.setViewAclsGroups(appListener.viewAclsGroups.getOrElse(""))
> {code}
> This will become a problem when ACLs is updated (newly added admin), only the new application can be effected, the old applications were still using the old ACLs. So these new admin still cannot check the logs of old applications.
> It is hard to say this is a bug, but in our scenario this is not the expected behavior we wanted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org