[
https://issues.apache.org/jira/browse/HADOOP-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653346#action_12653346
]
Enis Soztutar commented on HADOOP-4348:
---------------------------------------
I have a few questions regarding the patch :
#Is there any advantage of doing authentication check in RPC rather than
ipc.Server? If this one is better, then shouldn't ipc.Server#authorize() be an
abstract method rather than one with empty body.
# I understand that current configuration of policy is inline with queue
configuration. However I am not comfortable with Service and PolicyProvider
classes only holding key name ->protocol name mappings. I propose we
## introduce Configuration#keys() method returning key names in the
configuration.
## configure the acls like :
{code}
<property>
<name>security.connectionPermission.org.apache.hadoop.mapred.JobSubmissionProtocol</name>
<value>*</value>
<description></description>
</property>
{code}
## search for keys starting with prefix "security.connectionPermission" and
load them. Sure, the whole configuration keys will be searched, which is in the
order of 100s, but I guess it will be acceptable. Moreover we can use
configuration w/o default resources (see below).
#In ConfiguredPolicy#refresh() with every reload request conf.resources
arraylist gets appended which is a leak. I guess we should create a new
Configuration w/o loading default resources and add hadoop-policy.xml to it.
Alternatively we can get rid of hadoop-policy.xml, and configure everything
with hadoop-site.xml (core-site.xml), and use
Configuration#reloadConfiguration() in ConfiguredPolicy#refresh().
Minor things :
#mradmin and refresh-auth-policy seems good.
# the LOG.info() in ConfiguredPolicy#implies() seems redundant.
> 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
> Components: security
> Reporter: Kan Zhang
> Assignee: Arun C Murthy
> Fix For: 0.20.0
>
> Attachments: HADOOP-4348_0_20081022.patch,
> HADOOP-4348_1_20081201.patch, HADOOP-4348_2_20081202.patch,
> HADOOP-4348_3_20081204.patch, jaas_service_v1.patch, jaas_service_v2.patch,
> jaas_service_v3.patch, ServiceLevelAuthorization.pdf,
> ServiceLevelAuthorization.pdf
>
>
> 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.
