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)

Reply via email to