[
https://issues.apache.org/jira/browse/SENTRY-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007595#comment-14007595
]
SentryQA commented on SENTRY-191:
---------------------------------
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12646556/SENTRY-191.2.patch
against master.
{color:red}Overall:{color} -1 due to an error
{color:red}ERROR:{color} failed to build with patch (exit code 1)
Console output:
http://bigtop01.cloudera.org:8080/job/PreCommit-SENTRY-Build/81/console
This message is automatically generated.
> 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
> Assignee: Prasad Mujumdar
> Priority: Blocker
> Attachments: SENTRY-191.1.patch, SENTRY-191.2.patch
>
>
> 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)
