[
https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002667#comment-16002667
]
Robert Levas commented on AMBARI-20769:
---------------------------------------
[[email protected]]...
{{org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter}}
is an older class that we have been slowly phasing out due to its rather coarse
level of authorization. It only knows about URLs and in some cases, a few role
checks. The more granular control needs to access the payload data and works
off of lower-level permissions... where as a role is a group of permissions. We
can see that this older mechanism can be skipped by using
{{org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter#authorizationPerformedInternally}}
to check if the URL matches one where the provider can perform the more
granular authorization logic.
In the case of Decommission/Recommission, the logic to determine authorization
should be in the block of code near
{{org/apache/ambari/server/controller/internal/RequestResourceProvider.java:213}}.
However there seems to only be a clause for {{DECOMMISSION}}:
{code}
} else if (commandName.equals("DECOMMISSION")) {
if (!AuthorizationHelper.isAuthorized(resourceType, resourceId,
RoleAuthorization.SERVICE_DECOMMISSION_RECOMMISSION)) {
throw new AuthorizationException("The authenticated user is not
authorized to decommission services.");
}
{code}
Maybe this is correct or maybe there is a missing clause for "RECOMMISSION" - I
am not sure how this mechanism works. In any case, the following roles should
have this permission:
* SERVICE.OPERATOR
* SERVICE.ADMINISTRATOR
* CLUSTER.OPERATOR
* CLUSTER.ADMINISTRATOR
* AMBARI.ADMINISTRATOR
Have to walked through the code to make sure the code you pointed out is being
executed or not? In any case, that code block,
{noformat}
} else if (requestURI.matches(API_CLUSTERS_ALL_PATTERN)) {
if (permissionId.equals(PermissionEntity.CLUSTER_USER_PERMISSION)
||
permissionId.equals(PermissionEntity.CLUSTER_ADMINISTRATOR_PERMISSION)) {
authorized = true;
break;
}
{noformat}
Seems to be a hack to allow some logic to fall through given the user has some
role. In this case I do not think this block of code is involved.
So any issue you may be seeing might be related to the code in
{{org.apache.ambari.server.controller.internal.RequestResourceProvider}}.
> Recommission fails for Cluster Operators, Service Adminstrators and Service
> Operators
> -------------------------------------------------------------------------------------
>
> Key: AMBARI-20769
> URL: https://issues.apache.org/jira/browse/AMBARI-20769
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: trunk, 2.5.0
> Reporter: Keta Patel
> Assignee: Keta Patel
> Attachments: AMBARI-20769-codeSnippet-for-error.png,
> AMBARI-20769-codeSnippet.png
>
>
> Steps to reproduce:
> 1. Create 4 local users assign one to each of the following roles:
> - Cluster Administrator
> - Cluster Operator
> - Service Administrator
> - Service Operator
> 2. Logout and login back as one of the above created users.
> 3. Decommission a node, the operation is successful with the Background
> Operation pop-up showing the decommissioning operation being performed.
> 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is
> able to successfully perform this step. For the rest of the roles mentioned
> in step-1, you will see the following behavior:
> - The background operation pop-up shows up with "0 Operations" in progress.
> - The background operation pop-up disappears and you see the login page
> momentarily.
> - The main Dashboard is seen immediately after that and the node is still in
> the "Decommissioned" state.
> Desired Behavior:
> All the roles mentioned in step-1 must be able to successfully recommission
> the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
