These corrections were made on 9/2/2015 to this blog posting.

So... time to eat some crow. I had a customer who is automating their user onboarding process for his Hadoop cluster and wanted to know if he could use a linux account besides hdfs to create a HDFS user home directory and set the appropriate permissions – see simple hadoop cluster user provisioning process (simple = w/o pam or kerberos) . I told him he was out of luck and that was just the way it was going to be.

Thinking about it a bit later, I realized I actually never ran this one down. Navigating through the Hadoop site got me to http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html#The_Super-User which told me what I've been espousing all along; the user that starts up the NameNode (NN) is the superuser. Then I saw it – the phrase that let me know I was wrong in my reply...

In addition, the administrator may identify a distinguished group using a configuration parameter. If set, members of this group are also super-users.

Doh! I was definitely wrong in my thinking and reply to my customer. Hey, only the second time this month, but we have half a month to go!!

Let's see this in action. First, we need a test bed to work from. Let's use hdfs to create a test directory and then lock down the permissions to only the hdfs user.

[root@sandbox ~]# su hdfs 
[hdfs@sandbox root]$ hdfs dfs -mkdir /testSuperUser
[hdfs@sandbox root]$ hdfs dfs -mkdir /testSuperUser/testDirectory
[hdfs@sandbox root]$ hdfs dfs -ls /testSuperUser
Found 1 items
drwxr-xr-x   - hdfs hdfs          0 2014-08-13 22:42 /testSuperUser/testDirectory
[hdfs@sandbox root]$ hdfs dfs -chmod 700 /testSuperUser/testDirectory
[hdfs@sandbox root]$ hdfs dfs -ls /testSuperUser
Found 1 items
drwx------   - hdfs hdfs          0 2014-08-13 22:42 /testSuperUser/testDirectory

Now let's create an animals group with two users in it; cat and bat.

[hdfs@sandbox root]$ exit
exit
[root@sandbox ~]# groupadd animals
[root@sandbox ~]# useradd -ganimals cat
[root@sandbox ~]# useradd -ganimals bat
[root@sandbox ~]# lid -g animals
 cat(uid=1021)
 bat(uid=1022)

Then make sure they can't do anything that requires superuser access.

[root@sandbox ~]# su cat
[cat@sandbox root]$ hdfs dfs -ls /testSuperUser
Found 1 items
drwx------   - hdfs hdfs          0 2014-08-13 22:42 /testSuperUser/testDirectory
[cat@sandbox root]$ hdfs dfs -chgrp bogus /testSuperUser/testDirectory
chgrp: changing ownership of '/testSuperUser/testDirectory': Permission denied

No joy, but that is as expected. The instructions at http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html#Configuration_Parameters let me know I need to make sure there is a dfs.permissions.superusergroup KVP created for hdfs-site.xml. This parameter can be found in Ambari at Services > HDFS > Configs > Advanced > dfs.permissions.superusergroup. For my Hortonworks Sandbox this value is set to hdfs. This also aligns with the fact that unless you do a −chgrp, your newly created items have the group set to hdfs on this little pseudo-cluster. Contrary to what you would expect (i.e. the group becomes the value for this setting), I did find out later that even with a different superusergroup identified, the owning group stayed as hdfs.

[cat@sandbox root]$ exit
exit
[root@sandbox ~]# su turtle
[turtle@sandbox root]$ hdfs dfs -put /etc/group groups.txt
[turtle@sandbox root]$ hdfs dfs -ls 
Found 1 items
-rw-r--r--   1 turtle hdfs       1033 2014-08-13 23:12 groups.txt

After I changed the "superuser" group to be animals, I could then make the changes that I wanted to earlier.

[turtle@sandbox root]$ exit
exit
[root@sandbox ~]# su cat
[cat@sandbox root]$ hdfs dfs -ls /testSuperUser
Found 1 items
drwx------   - hdfs hdfs          0 2014-08-13 22:42 /testSuperUser/testDirectory
[cat@sandbox root]$ hdfs dfs -chgrp bogus /testSuperUser/testDirectory
[cat@sandbox root]$ hdfs dfs -ls /testSuperUser
Found 1 items
drwx------   - hdfs bogus          0 2014-08-13 22:42 /testSuperUser/testDirectory

I also did not screw up the fact that hdfs is my true superuser as shown by my "old" HDFS home directory process.

[cat@sandbox root]$ exit
exit
[root@sandbox ~]# useradd user1
[root@sandbox ~]# su hdfs
[hdfs@sandbox root]$ hdfs dfs -mkdir /user/user1
[hdfs@sandbox root]$ hdfs dfs -ls /user

   ... rm'd some lines ...  NOTICE THAT THE GROUP STILL DEFAULTS TO hdfs, NOT animals

drwxr-xr-x   - hdfs           hdfs           0 2014-08-13 23:49 /user/user1
[hdfs@sandbox root]$ hdfs dfs -chown user1 /user/user1
[hdfs@sandbox root]$ hdfs dfs -chgrp user1 /user/user1
[hdfs@sandbox root]$ hdfs dfs -ls /user

   ... rm'd some lines ...

drwxr-xr-x   - user1          user1          0 2014-08-13 23:49 /user/user1

Which can now also be done as a "real" user if set up appropriately. If bat had appropriate sudo rights, then I could have done the following without starting out at root.

[hdfs@sandbox root]$ exit
exit
[root@sandbox ~]# useradd user2
[root@sandbox ~]# su bat
[bat@sandbox root]$ hdfs dfs -mkdir /user/user2
[bat@sandbox root]$ hdfs dfs -ls /user

   ... rm'd some lines ...  NOTICE THAT THE GROUP STILL DEFAULTS TO hdfs, NOT animals

drwxr-xr-x   - user1          user1          0 2014-08-13 23:49 /user/user1
drwxr-xr-x   - bat            hdfs           0 2014-08-13 23:55 /user/user2
[bat@sandbox root]$ hdfs dfs -chown user2 /user/user2
[bat@sandbox root]$ hdfs dfs -chgrp user2 /user/user2
[bat@sandbox root]$ hdfs dfs -ls /user

   ... rm'd some lines ...

drwxr-xr-x   - user1          user1          0 2014-08-13 23:49 /user/user1
drwxr-xr-x   - user2          user2          0 2014-08-13 23:55 /user/user2

As usual, there are many ways to skin this cat and this simple property is the gateway to those choices. For many, the simple model of just adding the desired linux user(s) to the existing "superusers" group may be the way to go. If you are using this today, or might just do so, I'd love to hear your actual, or planned, approach.

hadoop superuser (you can have more than 'hdfs')