[
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.1.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, SENTRY-507.1.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)
