[ 
https://issues.apache.org/jira/browse/HADOOP-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13975748#comment-13975748
 ] 

Daryn Sharp commented on HADOOP-10448:
--------------------------------------

A few initial observations:  Less synchronization is always good, removing all 
synchronization will cause race conditions accessing the non-thread safe data 
structures during a refresh.  Does it make sense for get*ConfKey methods to be 
part of the api?  That seems like an implementation detail of a conf based 
provider that is inapplicable to other abstract providers.

While I like pluggable interfaces, I have concerns about this use case.  The 
proxy checks must be very performant to avoid stalling the jetty threads or 
limited number of ipc readers.  Stalling the readers is pretty serious!  I'm 
just curious what alternate implementation you intend to use?  Per the conf 
manageability concern, we use xml includes to break the proxy user config into 
a separate file.

> Support pluggable mechanism to specify proxy user settings
> ----------------------------------------------------------
>
>                 Key: HADOOP-10448
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10448
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: security
>    Affects Versions: 2.3.0
>            Reporter: Benoy Antony
>            Assignee: Benoy Antony
>         Attachments: HADOOP-10448.patch, HADOOP-10448.patch, 
> HADOOP-10448.patch, HADOOP-10448.patch, HADOOP-10448.patch
>
>
> We have a requirement to support large number of superusers. (users who 
> impersonate as another user) 
> (http://hadoop.apache.org/docs/r1.2.1/Secure_Impersonation.html) 
> Currently each  superuser needs to be defined in the core-site.xml via 
> proxyuser settings. This will be cumbersome when there are 1000 entries.
> It seems useful to have a pluggable mechanism to specify  proxy user settings 
> with the current approach as the default. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to