[
https://issues.apache.org/jira/browse/HADOOP-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556981#action_12556981
]
Doug Cutting commented on HADOOP-2531:
--------------------------------------
The use case of dfs.permissions=false was better explained to me yesterday. It
is intended to permit admins to set permissions after upgrade while leaving the
filesystem available for use. If this use case is really important, then we
should mark this "won't fix".
Nigel expressed concerns about displaying permissions in "ls" that are not
enforced would be confusing to users, that returning 777 would be better for
that reason too. But if dfs.permissions is only meant to be used during
transition, this may not be a serious issue.
I'm beginning to think that dfs.permissions should be 'true' by default, and
that the default permission on upgrade should be 777. That is back-compatible.
Then, if folks like, they can set more prohibitive permissions and/or disable
permission checking. If this is the default behavior then I am okay marking
this issue "won't fix". Currently dfs.permissions is 'false' by default, so
perhaps that should change. I am not yet certain what the default file
permission is after an upgrade...
> HDFS FileStatus.getPermission() should return 777 when dfs.permissions=false
> ----------------------------------------------------------------------------
>
> Key: HADOOP-2531
> URL: https://issues.apache.org/jira/browse/HADOOP-2531
> Project: Hadoop
> Issue Type: Bug
> Components: dfs
> Reporter: Doug Cutting
> Fix For: 0.16.0
>
>
> Generic permission checking code should still work correctly when
> dfs.permissions=false. Currently FileStatus#getPermission() returns the
> actual permission when dfs.permissions=false on the namenode, which is
> incorrect, since all accesses are permitted in this case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
