sentry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Yoder (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SENTRY-507) Ban additional configs in getConfigVal()
Date Tue, 28 Oct 2014 17:37:34 GMT

     [ https://issues.apache.org/jira/browse/SENTRY-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Yoder updated SENTRY-507:
------------------------------
    Attachment: SENTRY-507.0.patch

> Ban additional configs in getConfigVal()
> ----------------------------------------
>
>                 Key: SENTRY-507
>                 URL: https://issues.apache.org/jira/browse/SENTRY-507
>             Project: Sentry
>          Issue Type: Improvement
>    Affects Versions: 1.5.0
>            Reporter: Mike Yoder
>            Assignee: Mike Yoder
>            Priority: Minor
>             Fix For: 1.5.0
>
>         Attachments: SENTRY-507.0.patch
>
>
> Comments from [~bcwalrus] in email:
> {quote}
> Looking at SentryPolicyStoreProcessor.java, the forbidden configs are hardcoded in that
check.
> * You want to also forbid `sentry.store.jdbc.password' as well.
> * It'll get unwieldy as people add new sensitive configs. But I don't have any good idea
to keep this up-to-date.
> * Does this call require admin privilege? Why would normal users need to know the server
config?
> {quote}
> my reply
> {quote}
> Looking at SentryPolicyStoreProcessor.java, the forbidden configs are hardcoded in that
check.
> * You want to also forbid `sentry.store.jdbc.password' as well.
> Good point - it might just be easier to forbid ".*\.jdbc\..*" entirely - I can't see
how a client would want/need that.  Also should forbid ".*password.*" just to be sure. 
>  
> * It'll get unwieldy as people add new sensitive configs. But I don't have any good idea
to keep this up-to-date.
> A config option? :-) But that itself would have to be kept up to date.  
>  
> * Does this call require admin privilege? Why would normal users need to know the server
config?
> The use case for this is that impala would like to be able to cache certain config items,
like admin.group.  It's an internal call for clients.  Since the client is trusted (the other
calls simply pass the name of the requester) the lack of a requesting user isn't a big deal.
> {quote}
> This issue is to additionally ban ".jdbc." and "password".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message