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

Doug Cutting commented on HADOOP-4348:
--------------------------------------

Sanjay, I'm fine adding a session layer someday.  That would probably be useful.

Much of what you speak of is authentication, which may have to be session based 
rather than per-message.  But, so far as I can see, service-level authorization 
belongs somewhere between our two existing layers, so we need to choose one, 
rather arbitrarily.  My initial observation was merely, with the two layers we 
have now, it would be more simply implemented at the RPC layer.  Looking at the 
patch, i think would take fewer lines of easier-to-read code to implement this 
feature there.  (Compare earlier with later versions of HADOOP-4049.)  
Authorization, as specified in this issue, requires just a lookup of the 
username and group in a hashtable, so performance should not be an issue.

So if we want to add service-level authorization now, without first 
re-architecting things, and we don't see a strong performance or functionality 
reason against checking service-level authorization per-request, then we should 
put it at the RPC layer.  If we later re-architect things into more layers, as 
we probably should, then service-level authorization will end up in some new, 
intermediate layer.

My initial comments were a response to the patch, not an architectural treaty.  
Let's keep things grounded in code.  If someone wants to re-architect RPC in 
this patch, that's fine.  But until then, we need to decide how to fit the 
desired feature into the existing code while making the least mess.  If someone 
can contribute a patch which implements this feature as cleanly and simply at 
the IPC level alone as I think it can be done at the RPC level that'd be great.

> 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
>
>         Attachments: HADOOP-4348_0_20081022.patch, jaas_service_v1.patch
>
>
> 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