[
https://issues.apache.org/jira/browse/HADOOP-10779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14053927#comment-14053927
]
Colin Patrick McCabe commented on HADOOP-10779:
-----------------------------------------------
Supergroup is an HDFS-specific concept that doesn't appear in most other
filesystems. It doesn't make sense to add a generic key, because the concept
itself is not generic.
UNIX has something vaguely similar to supergroup, in the wheel group or admin
group. All members of the wheel group can su to root. But this is not exactly
the same as the supergroup concept in HDFS, since no su or sudo is required in
HDFS.
I would say the superuser / supergroup concept in HDFS is an artifact of the
desire to develop and run HDFS in userspace without being root. For
filesystems such as Lustre that run in kernel-space, this is a non-issue (you
have to be root to fool with the kernel anyway).
> Generalize DFS_PERMISSIONS_SUPERUSERGROUP_KEY for any HCFS
> ----------------------------------------------------------
>
> Key: HADOOP-10779
> URL: https://issues.apache.org/jira/browse/HADOOP-10779
> Project: Hadoop Common
> Issue Type: Wish
> Components: fs
> Reporter: Martin Bukatovic
> Priority: Minor
>
> HDFS has configuration option {{dfs.permissions.superusergroup}} stored in
> {{hdfs-site.xml}} configuration file:
> {noformat}
> <property>
> <name>dfs.permissions.superusergroup</name>
> <value>supergroup</value>
> <description>The name of the group of super-users.</description>
> </property>
> {noformat}
> Since we have an option to use alternative Hadoop filesystems (HCFS), there is
> a question how to specify a supergroup in such case.
> Eg. would introducing HCFS option in say {{core-site.xml}} for this as shown
> below make sense?
> {noformat}
> <property>
> <name>hcfs.permissions.superusergroup</name>
> <value>${dfs.permissions.superusergroup}</value>
> <description>The name of the group of super-users.</description>
> </property>
> {noformat}
> Or would you solve it in different way? I would like to at least declare
> a recommended approach for alternative Hadoop filesystems to follow.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
