[
https://issues.apache.org/jira/browse/HADOOP-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643117#action_12643117
]
acmurthy edited comment on HADOOP-4348 at 10/27/08 7:43 PM:
-----------------------------------------------------------------
@Sanjay/Doug - It's fairly easy to push it down a level from RPC to IPC by
passing in the AuthorizationManager, so I agree. However I'm a tad reluctant
since I believe it's fair-game to have a hook on connection-setup, rather than
leak the AuthorizationManager into the IPC layer... *shrug*.
@Enis - Thanks for the JAAS patch, I spent a fair bit of time researching - my
take:
1. The 'policy' file is extremely ungainly and very hard to use. It also is
'principal-centric' and we'd really like it to be resource-centric i.e. the
'protocol' in this case (as in: who can access JobSubmissionProtocol?). I
cannot seem to find a way around using the policy file at all i.e. say plugin
our own ACL list via a config file and get AccessController.checkPermission to
use it. I do see java.security.Policy, but I don't see it having the
abstractions we need?
2. We really do not want to turn on the Java Security Manager, it has a
significant performance penalty. From what I gather (http://www.jaasbook.com/
and specifically http://www.jaasbook.com/pdfs/jaas-in-action_chapter05-03.pdf)
it turns out that the recommended way to use AccessController.checkPermission
is via SecurityManager.checkPermission(). Something to keep in mind.
I'd love your take on this - maybe I'm missing other features of JAAS? However,
I think the 2 points we need to keep in mind are the same: do not use the java
policy file and turn off the SecurityManager.
Thoughts?
was (Author: acmurthy):
@Sanjay/Doug - It's fairly easy to push it down a level from RPC to IPC by
passing in the AuthorizationManager, so I agree. However I'm a tad reluctant
since I believe it's fair-game to have a hook on connection-setup, rather than
leak the AuthorizationManager into the IPC layer... *shrug*.
@Enis - Thanks for the JAAS patch, I spent a fair bit of time researching - my
take:
1. The 'policy' file is extremely ungainly and very hard to use. It also is
'principal-centric' and we'd really like it to be resource-centric i.e. the
'protocol' in this case (as in: who can access JobSubmissionProtocol?). I
cannot seem to find a way around using the policy file at all i.e. say plugin
our own ACL list via a config file etc. I do see java.security.Policy, but I
don't see it having the abstractions we need?
2. We really do not want to turn on the Java Security Manager, it has a
significant performance penalty. From what I gather (http://www.jaasbook.com/
and specifically http://www.jaasbook.com/pdfs/jaas-in-action_chapter05-03.pdf)
it turns out that the recommended way to use AccessController.checkPermission
is via SecurityManager.checkPermission(). This might be trouble!
I'd love your take on this - maybe I'm missing other features of JAAS? However,
I think the 2 points we need to keep in mind are the same: do not use the java
policy file and turn off the SecurityManager.
Thoughts?
> 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.
