[
https://issues.apache.org/jira/browse/SENTRY-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997087#comment-13997087
]
Sravya Tirukkovalur commented on SENTRY-191:
--------------------------------------------
[~lskuff], thats a good point. It might be possible to handle grant/revoke
statements authorization as part of binding layer:
https://github.com/apache/incubator-sentry/blob/master/sentry-binding/sentry-binding-hive/src/main/java/org/apache/sentry/binding/hive/authz/HiveAuthzPrivilegesMap.java#L163
I will need to dig a little more though to understand whats the best way to
achieve it.
> Sentry Policy Service should not require passing the RPC requestor's
> user/group information
> -------------------------------------------------------------------------------------------
>
> Key: SENTRY-191
> URL: https://issues.apache.org/jira/browse/SENTRY-191
> Project: Sentry
> Issue Type: Bug
> Affects Versions: 1.3.0
> Reporter: Lenni Kuff
> Priority: Blocker
>
> Sentry Policy Service should not require passing the RPC requestor's
> user/group information. Currently this is done to "authorize" whether a user
> can execute a GRANT/REVOKE statement since only pre-selected set of admin
> users run grant/revoke statements. This does not seem very secure and also
> couples "authorization" with the storing of policy metadata.
> I propose that instead of this model, a default "admin" role be introduced.
> On Sentry Service startup the the role be populated with set of valid admin
> users as specified in the sentry-service.xml configuration file.
> When GRANT/REVOKE statements are run they should be treated the same as any
> other SQL statement and authorized at the binding layer (if the give user
> isn't part of the "admin" role then fail the request).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
