[jira] [Updated] (SENTRY-507) Ban additional configs in getConfigVal()

["Mike Yoder (JIRA)" <ji...@apache.org>]

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