hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen Wittenauer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-1701) Provide a simple authentication service and a user management service
Date Wed, 15 Aug 2007 22:03:36 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520110
] 

Allen Wittenauer commented on HADOOP-1701:
------------------------------------------

Some thoughts/concerns...

1) While I realize the first pass was to not actually have passwords, I think it would be
beneficial to at least have fields for passwords in such things as users.txt and have the
actual authentication stuff just ignore the password field.  People will want to automate,
and not having the placeholders there will make life hard as things progress.

2) If the plan is for POSIX-like, where is the default gid in this file as well? Where do
group definitions live?

3) Negative user ids are/were used in UNIX, and in particular, for nobody on NFS.  Using something
similar to NFSv4 ID Domains could deal with the issues of private/public username space without
having to resort to uid reservations.   Additionally, have we looked into support NFSv4-style
ACLs?  It would be good to be as compatible as possible with NFSv4 to open the door for a
NFSv4.1 implementation down the road, IMHO.

4) What's the plan for default ownership, etc, during upgrade?  What's the equivalent of chown,
chgrp, etc?  Sticky bits?  

5) I'd like to keep the default user configurable.  I can see where it would be useful to
change it under certain conditions, especially when tied to something to like Kerberos.

6) What are the 'rules' governing usernames?  What are the legal characters?  Length?  What
are the rules governing uids?  [It would be good to look at POSIX for guidance here.]

7) What happens when the user database gets large? What kind of memory footprint will be required
per user? For example, what happens if we have 100,000 users defined?



> Provide a simple authentication service and a user management service
> ---------------------------------------------------------------------
>
>                 Key: HADOOP-1701
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1701
>             Project: Hadoop
>          Issue Type: New Feature
>            Reporter: Tsz Wo (Nicholas), SZE
>            Assignee: Tsz Wo (Nicholas), SZE
>         Attachments: 1701_20070813c.patch, users.txt
>
>
> In HADOOP-1298, we want to add user information and permission to the file system.  It
requires an authentication service and a user management service.  We should provide a framework
and a simple implementation in issue and extend it later.  As discussed in HADOOP-1298, the
framework should be extensible and pluggable.
> - Extensible: possible to extend the framework to the other parts (e.g. map-reduce) of
Hadoop.
> - Pluggable: can easily switch security implementations.  Below is a diagram borrowed
from Java.
> !http://java.sun.com/javase/6/docs/technotes/guides/security/overview/images/3.jpg!
> - Implement a Hadoop authentication center (HAC).  In the first step, the mechanism of
HAC is very simple, it keeps track a list of usernames (we only support users, will work on
other principals later) in HAC and verify username in user login (yeah, no password).  HAC
can run inside NameNode or run as a stand alone server.   We will probably use Kerberos to
provide more sophisticated authentication service.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message