[
https://issues.apache.org/jira/browse/AMBARI-21016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009733#comment-16009733
]
Robert Levas commented on AMBARI-21016:
---------------------------------------
[~yaolei],
I do not think your solution covers all cases. Did you try the case where you
give the user more permissions or try using direct REST API calls using
cookies.
The changes in [^AMBARI-21016.patch] only seem to cover the case in an Ambari
UI scenario where the user is given less permissions. This causes the UI to
hide operations that the user is no longer supposed to have. However I believe
due to the stored session information, the backend still thinks the user has
the removed permissions. This can be tested by giving the user more
permissions, allowing your patch to show more options for the user. But I
believe that the backend will return errors since the user is not authorized to
perform the operations because the _old_ permission set is stored in session.
I don't necessarily think that this is an issue since changing
roles/groups/permissions for a user when they are logged in usually requires
the user to log out and the log back in to realize the changes. I believe that
UNIX and Linux works this way. So, I was not concerted about this _issue_.
I wonder what other team members feel about this. [~u39kun],
[[email protected]], [~jonathan.hurley], [~stoader]
> RBAC:Ambari should be sensitve to the change of login user's permissions.
> -------------------------------------------------------------------------
>
> Key: AMBARI-21016
> URL: https://issues.apache.org/jira/browse/AMBARI-21016
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
> Affects Versions: trunk
> Reporter: Yao Lei
> Assignee: Yao Lei
> Fix For: trunk, 2.5.1
>
> Attachments: AMBARI-21016.patch
>
>
> Steps to reproduce:
> 1.Login ambari with ambari administrator role and create a user named Test on
> host A.
> 2.Assign service administrator role(or any other one of five roles) to this
> user Test.
> 3.On host B, login ambari with user Test .Now it plays as a service
> administrato role.
> 4.On host A, unassign the role of user Test , or change the role to another
> one, or even delete this user.
> 5.On host B, we will find the user Test can continue to operate ambari with
> previous permissions as a service administrator which actually have already
> changed by step 4.
> Except for on two different hosts, we also can reproduce this problem between
> two different browsers on local host.
> One solution:
> Periodly schedule a task to update current user's authorization. If any error
> happens in this process, we should log off current user.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
