hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Owen O'Malley" <omal...@apache.org>
Subject Re: hadoop.job.ugi backwards compatibility
Date Mon, 13 Sep 2010 16:31:35 GMT
Moving the discussion over to the more appropriate mapreduce-dev.

On Mon, Sep 13, 2010 at 9:08 AM, Todd Lipcon <todd@cloudera.com> wrote:

> 1) Groups resolution happens on the server side, where it used to happen on
> the client. Thus, all Hadoop users must exist on the NN/JT machines in order
> for group mapping to succeed (or the user must write a custom group mapper).

There is a plugin that performs the group lookup. See HADOOP-4656.
There is no requirement for having the user accounts on the NN/JT
although that is the easiest approach. It is not recommended that the
users be allowed to login.

I think it is important that turning security on and off doesn't
drastically change the semantics or protocols. That will become much
much harder to support downstream.

> 2) The hadoop.job.ugi parameter is ignored - instead the user has to use the
> new UGI.createRemoteUser("foo").doAs() API, even in simple security.

User code that counts on hadoop.job.ugi working will be horribly
broken once you turn on security. Turning on and off security should
not involve testing all of your applications. It is unfortunate that
we ever used the configuration value as the user, but continuing to
support it will make our user's code much much more brittle.

-- Owen

Mime
View raw message