Mike Yoder created SENTRY-507:
---------------------------------
Summary: 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
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)