[
https://issues.apache.org/jira/browse/HADOOP-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun C Murthy updated HADOOP-4348:
----------------------------------
Attachment: HADOOP-4348_4_20081205.patch
Correct patch.
All unit tests pass...
{noformat}
[exec] -1 overall.
[exec]
[exec] +1 @author. The patch does not contain any @author tags.
[exec]
[exec] +1 tests included. The patch appears to include 28 new or
modified tests.
[exec]
[exec] +1 javadoc. The javadoc tool did not generate any warning
messages.
[exec]
[exec] +1 javac. The applied patch does not increase the total number
of javac compiler warnings.
[exec]
[exec] +1 findbugs. The patch does not introduce any new Findbugs
warnings.
[exec]
[exec] -1 Eclipse classpath. The patch causes the Eclipse classpath to
differ from the contents of the lib directories.
{noformat}
I'm not sure why test-patch.sh is complaining about Eclipse classpath - this
patch certainly doesn't introduce any new jars.
Here is the relevant output I can't seem to make sense of:
{noformat}
[exec]
======================================================================
[exec]
======================================================================
[exec] Running Eclipse classpath verification.
[exec]
======================================================================
[exec]
======================================================================
[exec]
[exec]
[exec]
[exec] FAILED. Some jars are not declared in the Eclipse project.
[exec] Declared jars: lib/commons-cli-2.0-SNAPSHOT.jar
[exec] lib/commons-codec-1.3.jar
[exec] lib/commons-httpclient-3.0.1.jar
[exec] lib/commons-logging-1.0.4.jar
[exec] lib/commons-logging-api-1.0.4.jar
[exec] lib/commons-net-1.4.1.jar
[exec] lib/hsqldb-1.8.0.10.jar
[exec] lib/jets3t-0.6.1.jar
[exec] lib/jetty-6.1.14.jar
[exec] lib/jetty-util-6.1.14.jar
[exec] lib/jsp-2.1/core-3.1.1.jar
[exec] lib/jsp-2.1/jsp-2.1.jar
[exec] lib/jsp-2.1/jsp-api-2.1.jar
[exec] lib/junit-3.8.1.jar
[exec] lib/kfs-0.2.2.jar
[exec] lib/log4j-1.2.15.jar
[exec] lib/oro-2.0.8.jar
[exec] lib/servlet-api-2.5-6.1.14.jar
[exec] lib/slf4j-api-1.4.3.jar
[exec] lib/slf4j-log4j12-1.4.3.jar
[exec] lib/xmlenc-0.52.jar
[exec] src/test/lib/ftplet-api-1.0.0-SNAPSHOT.jar
[exec] src/test/lib/ftpserver-core-1.0.0-SNAPSHOT.jar
[exec] src/test/lib/ftpserver-server-1.0.0-SNAPSHOT.jar
[exec] src/test/lib/mina-core-2.0.0-M2-20080407.124109-12.jar
[exec] Present jars: lib//commons-cli-2.0-SNAPSHOT.jar
[exec] lib//commons-codec-1.3.jar
[exec] lib//commons-httpclient-3.0.1.jar
[exec] lib//commons-logging-1.0.4.jar
[exec] lib//commons-logging-api-1.0.4.jar
[exec] lib//commons-net-1.4.1.jar
[exec] lib//hsqldb-1.8.0.10.jar
[exec] lib//jets3t-0.6.1.jar
[exec] lib//jetty-6.1.14.jar
[exec] lib//jetty-util-6.1.14.jar
[exec] lib//jsp-2.1/core-3.1.1.jar
[exec] lib//jsp-2.1/jsp-2.1.jar
[exec] lib//jsp-2.1/jsp-api-2.1.jar
[exec] lib//junit-3.8.1.jar
[exec] lib//kfs-0.2.2.jar
[exec] lib//log4j-1.2.15.jar
[exec] lib//oro-2.0.8.jar
[exec] lib//servlet-api-2.5-6.1.14.jar
[exec] lib//slf4j-api-1.4.3.jar
[exec] lib//slf4j-log4j12-1.4.3.jar
[exec] lib//xmlenc-0.52.jar
[exec] src/test/lib//ftplet-api-1.0.0-SNAPSHOT.jar
[exec] src/test/lib//ftpserver-core-1.0.0-SNAPSHOT.jar
[exec] src/test/lib//ftpserver-server-1.0.0-SNAPSHOT.jar
[exec] src/test/lib//mina-core-2.0.0-M2-20080407.124109-12.jar
{noformat}
> 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, HADOOP-4348_4_20081205.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.
