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

Kan Zhang commented on HADOOP-4348:
-----------------------------------

I see. We could do something similar here for our user list. Using hadoop-site 
instead of a separate conf file is one less file to manage. We don't have 
semantics like '*' or blank. A client is either a valid user or not.

> Adding service-level authorization to Hadoop
> --------------------------------------------
>
>                 Key: HADOOP-4348
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4348
>             Project: Hadoop Core
>          Issue Type: New Feature
>            Reporter: Kan Zhang
>            Assignee: Arun C Murthy
>             Fix For: 0.20.0
>
>
> Service-level authorization is the initial checking done by a Hadoop service 
> to find out if a connecting client is a pre-defined user of that service. If 
> not, the connection or service request will be declined. This feature allows 
> services to limit access to a clearly defined group of users. For example, 
> service-level authorization allows "world-readable" files on a HDFS cluster 
> to be readable only by the pre-defined users of that cluster, not by anyone 
> who can connect to the cluster. It also allows a M/R cluster to define its 
> group of users so that only those users can submit jobs to it.
> Here is an initial list of requirements I came up with.
>     1. Users of a cluster is defined by a flat list of usernames and groups. 
> A client is a user of the cluster if and only if her username is listed in 
> the flat list or one of her groups is explicitly listed in the flat list. 
> Nested groups are not supported.
>     2. The flat list is stored in a conf file and pushed to every cluster 
> node so that services can access them.
>     3. Services will monitor the modification of the conf file periodically 
> (5 mins interval by default) and reload the list if needed.
>     4. Checking against the flat list is done as early as possible and before 
> any other authorization checking. Both HDFS and M/R clusters will implement 
> this feature.
>     5. This feature can be switched off and is off by default.
> I'm aware of interests in pulling user data from LDAP. For this JIRA, I 
> suggest we implement it using a conf file. Additional data sources may be 
> supported via new JIRA's.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to