[
https://issues.apache.org/jira/browse/HDFS-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997747#comment-13997747
]
Chris Nauroth commented on HDFS-6399:
-------------------------------------
Hi, Charles. Thanks for filing this.
The {{isPermissionEnabled}} checks were left out on purpose for consistency
with the existing behavior of setting {{dfs.permissions.enabled}} to {{false}}
as documented in the HDFS Permissions Guide.
http://hadoop.apache.org/docs/r2.4.0/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html
Quoting from near the bottom of that page:
{quote}
Regardless of whether permissions are on or off, chmod, chgrp and chown always
check permissions. These functions are only useful in the permissions context,
and so there is no backwards compatibility issue. Furthermore, this allows
administrators to reliably set owners and permissions in advance of turning on
regular permissions checking.
{quote}
In the implementation, this means that {{FSNamesystem#setPermissionInt}} skips
the check for {{isPermissionEnabled}}. The ACL modification operations are
somewhat analogous to a chmod, so we followed the same pattern.
However, this may not have been clear enough, so I think it would be worthwhile
to update that text in the HDFS Permissions Guide to mention that the same
thing applies to setfacl.
> FSNamesystem ACL operations should check isPermissionEnabled
> ------------------------------------------------------------
>
> Key: HDFS-6399
> URL: https://issues.apache.org/jira/browse/HDFS-6399
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Reporter: Charles Lamb
> Assignee: Charles Lamb
> Priority: Minor
> Attachments: HDFS-6399.1.patch
>
>
> The ACL operations in FSNamesystem don't currently check isPermissionEnabled
> before calling checkOwner(). This patch corrects that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
