[
https://issues.apache.org/jira/browse/RANGER-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18048772#comment-18048772
]
Madhan Neethiraj commented on RANGER-5399:
------------------------------------------
[~sanketshelar] - grant/revoke calls by services like Impala/HiveServer2/HBase
authenticate with Ranger admin using their service account. The identity of the
user entering grant/revoke statement is sent in grantor field of the payload.
Ranger admin ensures that the grantor user has necessary privileages to perform
the grant/revoke call. If the grantor user doesn't have privileges, the
grant/revoke must fail. This is the correct behavior.
The suggested fix of using service account identity (impala/hive/hbase) to
authorize grant/revoke calls is incorrect.
> Ranger: HTTP 403 - User '' lacks delegated-admin privilege when attempting to
> GRANT privilege on a database
> -----------------------------------------------------------------------------------------------------------
>
> Key: RANGER-5399
> URL: https://issues.apache.org/jira/browse/RANGER-5399
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
> Affects Versions: 3.0.0
> Reporter: Sanket Shelar
> Assignee: Sanket Shelar
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Steps to reproduce
> 1. create a user and kinit using it.
> 2. Login into impala shell
> 3. verify the user using select user(); to confirm kinit user.
> 4. Create database -
> create database test_db;
> 5. grant a privilege on the new database to another user
> grant alter on database test_db to USER hive;
> Expected result -
> Grant policy should be created
> Actual result -
> Grant cmd failed with message
> message: HTTP 403 Error: User 'livy' does not have delegated-admin privilege
> on given resources
> The issue began after RANGER-4771, where the ensureAdminAccess() method was
> updated to prioritize the grantor for determining userName, isAdmin, and
> isKeyAdmin, instead of always using the session user.
> As a result, the operation now fails when the grantor lacks admin or
> delegated-admin privileges. Previously, bizUtil.getCurrentUserLoginId()
> (session user) was used, allowing the scenario to succeed.
> Before this change, the session user in the scenario was impala (instead of
> the kinit user), which enabled the GRANT command to succeed.
> Similar behavior was observed in Beeline and HBase shells for same scenario,
> where the session users were hive and hbase respectively, even if the kinit
> user differs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
