Thanks Nicolas, I read it yet again (ok, only the third time). Yes it
talks of whoami, I actually knew that from single stepping the client
too, I was still stuck. It mentioned the posix model, kinda guessed
that also from the javadocs. From Dougs note it clearly states that
"No foo account need to exist on the namenode" and that the only
exception is the user that started the server. I didnt get that
clarity from the perms doc. Perhaps an example for the case where
there are users other than that that started the server....I would of
thought this was a common one. In our office we dumped this on a
bunch of linux boxes that all share the same username, but all our
developers are using macs with their own user name and they dont
expect to have their own user on the linux boxes (cause we are lazy
that way).
For instance, that all it requires is for me to create the ability for
say a mac user with login of bob to access things under /bob is for me
to go in as the super user and do something like:
hadoop dfs -mkdir /bob
hadoop dfs -chown bob /bob
where bob literally doesnt exist on the hdfs box and was not mentioned
prior to those two commands.
On Jun 11, 2008, at 10:00 PM, [EMAIL PROTECTED] wrote:
This information can be found in
http://hadoop.apache.org/core/docs/current/hdfs_permissions_guide.html
Nicholas
----- Original Message ----
From: Chris Collins <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, June 11, 2008 9:31:18 PM
Subject: Re: client connect as different username?
Thanks Doug, should this be added to the permissions doc or to the
faq? See you in Sonoma.
C
On Jun 11, 2008, at 9:15 PM, Doug Cutting wrote:
Chris Collins wrote:
You are referring to creating a directory in hdfs? Because if I am
user chris and the hdfs only has user foo, then I cant create a
directory because I dont have perms, infact I cant even connect.
Today, users and groups are declared by the client. The namenode
only records and checks against user and group names provided by the
client. So if someone named "foo" writes a file, then that file is
owned by someone named "foo" and anyone named "foo" is the owner of
that file. No "foo" account need exist on the namenode.
The one (important) exception is the "superuser". Whatever user
name starts the namenode is the superuser for that filesystem. And
if "/" is not world writable, a new filesystem will not contain a
home directory (or anywhere else) writable by other users. So, in a
multiuser Hadoop installation, the superuser needs to create home
directories and project directories for other users and set their
protections accordingly before other users can do anything. Perhaps
this is what you've run into?
Doug
