[
https://issues.apache.org/jira/browse/HADOOP-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652064#action_12652064
]
Enis Soztutar commented on HADOOP-4348:
---------------------------------------
Here is my take on the patch :
# I could not understand the difference between AuthorizationEx and
AccessControlEx. Doesn't "access control" imply "authorization" ?
# Why do we set the policy in use in all the places (TT, DN, JT, etc) instead
of setting it once in SecurityUtil?
# instead of passing UGI in connection header, we should pass Subject(and
create the UGI from Subject, not the other way). The authentication can be
enforced during the creation of Subject which should be done at the client
side. Then for kerberos based authentication, we can check the credentials of
the Subject.
# I am not big fan of introducing a custom hadoop-policy file with a new
syntax(in my version of the patch), however I think it is more general,
extensible and simpler than this version.
- The permission / principal mapping is really a many to many relation, so it
does not naturally fit in property name/value type of configuration.
- having
Service/ServiceAuthorizationManager/PolicyProvider/HDFSPolicyProvider/MapReducePolicyProvider/
classes just for having property name/value style configuration seems to be an
overkill.
- For introducing a new type of permission(not a service level
authorization), we should introduce many classes in this design. Moreover
ConfiguredPolicy does not capture future authentication points (such as job
level, file access, ... )
- It is not clear how we can configure other types of (future) permissions
with this schema. For example if we would like to introduce permissions for
each method in protocols, we cannot easily configure them.
minor issues :
# hadoop.security.authorization should default to false in hadoop-default.xml.
# system.err output in SecurityUtil.setPolicy seems redundant.
# for setting acl list from conf, we can prefix group names with ":" similar to
unix style. For example <name> foo, bar, :hadoop </name> meaning to give
permissions for users foo, bar and group hadoop
# some log.info can be changed to log.debug in ipc.Server with guards. In case
of dos attacks lots of log will be output if the server runs in info mode.
> 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,
> HADOOP-4348_1_20081201.patch, jaas_service_v1.patch, jaas_service_v2.patch,
> jaas_service_v3.patch, 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.
