1. As follows, the initial ownership group is supergroup, instead of any
group of the operation user.
[zk@hadoop-nn ~]$ whoami
zk
[zk@hadoop-nn ~]$ id -Gn
zk ldapgroup
[zk@hadoop-nn ~]$ echo "test hadoop cluster" > hadoop-test
[zk@hadoop-nn ~]$ ls -l hadoop-test
-rw-rw-r--. 1 zk zk 20 Sep 7 04:33 hadoop-test
[zk@hadoop-nn ~]$ hadoop dfs -copyFromLocal hadoop-test /usr/hadoop/tmp/zk/
[zk@hadoop-nn ~]$ hadoop dfs -lsr /usr/hadoop/tmp/zk/
-rw-r--r-- 1 zk supergroup 20 2012-09-07 04:33
/usr/hadoop/tmp/zk/hadoop-test
Relevant hadoop configurations are below.
hadoop.security.authentication --> Kerberos
dfs.permissions --> true
hadoop.security.authorization --> true
2. Looking at the codes, found the behavior is intended.
In 1.0.3, in NameNode.java,
/** {@inheritDoc} */
public void create(String src,
FsPermission masked,
...) throws IOException {
...
namesystem.startFile(src,
new
PermissionStatus(UserGroupInformation.getCurrentUser().getShortUserName(),
null, masked),
clientName, clientMachine, overwrite, createParent, replication,
blockSize);
..
}
In hadoop trunk,
@Override // ClientProtocol
public void create(String src,
FsPermission masked,
String clientName,
...) throws IOException {
...
namesystem.startFile(src,
new
PermissionStatus(UserGroupInformation.getCurrentUser().getShortUserName(),
null, masked),
clientName, clientMachine, flag.get(), createParent, replication,
blockSize);
...
}
We can see that null value as the group parameter is given for
PermissionStatus(String user, String group, FsPermission permission).
3. So the question is, why Hadoop intends for that, using the default
value 'supergroup' as the initial ownership group for newly created files?
If so, how fs permission checker checks permission against the file group? I
guess it's not so relevant then.
I'm learning Hadoop, and everything is new and interested. Thanks for answers,
corrections, and anything.
Kai
