[
https://issues.apache.org/jira/browse/HDFS-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harsh J updated HDFS-3074:
--------------------------
Description:
When creating a file or making a directory on HDFS, the namesystem calls pass
{{null}} for the group name, thereby having the parent directory permissions
inherited onto the file.
This is not how the Linux FS works at least.
For instance, if I have today a user 'foo' with default group 'foo', and I have
my HDFS home dir created as "foo:foo" by the HDFS admin, all files I create
under my directory too will have "foo" as group unless I chgrp them myself.
This makes sense.
Now, if my admin were to change my local accounts' default/primary group to
'bar' (but did not change so on my homedir on HDFS, and I were to continue
writing files to my home directory or any subdirectory that has 'foo' as group,
all files still get created with group 'foo' - as if the NN has not realized
the primary group of the mapped shell account has already changed.
On linux this is the opposite. My login session's current primary group is what
determines the default group on my created files and directories, not the
parent dir owner.
If the create and mkdirs call passed UGI's group info
(UserGroupInformation.getCurrentUser().getGroupNames()[0] should give primary
group?) along into their calls instead of a null in the PermissionsStatus
object, perhaps this can be avoided.
Or should we leave this as-is, and instead state that if admins wish their
default groups of users to change, they'd have to chgrp all the directories
themselves?
was:
When creating a file or making a directory on HDFS, the namesystem calls pass
{{null}} for the group name, thereby having the parent directory permissions
inherited onto the file.
This is not how the Linux FS works at least.
For instance, if I have today a user 'foo' with default group 'foo', and I have
my HDFS home dir created as "foo:foo" by the HDFS admin, all files I create
under my directory too will have "foo" as group unless I chgrp them myself.
This makes sense.
Now, if my admin were to change my local accounts' default/primary group to
'bar' (but did not change so, and I were to continue writing files to my home
directory (or any subdirectory that has 'foo' as group), all files still get
created with group 'foo' - as if the NN has not realized the primary group has
changed.
On linux this is the opposite. My login session's current primary group is what
determines the default group on my created files and directories, not the
parent dir owner.
If the create and mkdirs call passed UGI's group info
(UserGroupInformation.getCurrentUser().getGroupNames()[0] should give primary
group?) along into their calls instead of a null in the PermissionsStatus
object, perhaps this can be avoided.
Or should we leave this as-is, and instead state that if admins wish their
default groups of users to change, they'd have to chgrp all the directories
themselves?
> HDFS ignores group of a user when creating a file or a directory, and instead
> inherits
> --------------------------------------------------------------------------------------
>
> Key: HDFS-3074
> URL: https://issues.apache.org/jira/browse/HDFS-3074
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.23.1
> Reporter: Harsh J
> Priority: Minor
>
> When creating a file or making a directory on HDFS, the namesystem calls pass
> {{null}} for the group name, thereby having the parent directory permissions
> inherited onto the file.
> This is not how the Linux FS works at least.
> For instance, if I have today a user 'foo' with default group 'foo', and I
> have my HDFS home dir created as "foo:foo" by the HDFS admin, all files I
> create under my directory too will have "foo" as group unless I chgrp them
> myself. This makes sense.
> Now, if my admin were to change my local accounts' default/primary group to
> 'bar' (but did not change so on my homedir on HDFS, and I were to continue
> writing files to my home directory or any subdirectory that has 'foo' as
> group, all files still get created with group 'foo' - as if the NN has not
> realized the primary group of the mapped shell account has already changed.
> On linux this is the opposite. My login session's current primary group is
> what determines the default group on my created files and directories, not
> the parent dir owner.
> If the create and mkdirs call passed UGI's group info
> (UserGroupInformation.getCurrentUser().getGroupNames()[0] should give primary
> group?) along into their calls instead of a null in the PermissionsStatus
> object, perhaps this can be avoided.
> Or should we leave this as-is, and instead state that if admins wish their
> default groups of users to change, they'd have to chgrp all the directories
> themselves?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
