sentry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sravya Tirukkovalur (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SENTRY-191) Sentry Policy Service should not require passing the RPC requestor's user/group information
Date Wed, 14 May 2014 00:25:16 GMT

    [ https://issues.apache.org/jira/browse/SENTRY-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997093#comment-13997093
] 

Sravya Tirukkovalur commented on SENTRY-191:
--------------------------------------------

Also would like to add that the current approach has no problem from security stand point,
as Sentry service selectively allows connections using "sentry.service.allow.connect". So
only trusted users are allowed to connect and modify policy meta data.

> 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)

Mime
View raw message