[
https://issues.apache.org/jira/browse/HADOOP-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558879#action_12558879
]
Doug Cutting commented on HADOOP-2543:
--------------------------------------
> Explicitly tightening them is more backwards compatible, but from the
> security point of view, explicitly loosening them is safer.
Yes, and for this upgrade, back-compatibility is more important than
immediately increasing security. We don't decrease security any, and folks can
easily increase security after the upgrade by tightening permissions. But we
don't want things to be broken as soon as they upgrade by automatically
tightening permissions.
What I'm proposing is essentially the use-case you describe above for using
dfs.permission=false, but without setting that: after the upgrade everything is
permitted, and folks can start restricting access, but without having to
restart the cluster. I think for most sites this is simpler, less surprising
and sufficient.
> No-permission-checking mode for smooth transition to 0.16's permissions
> features.
> ----------------------------------------------------------------------------------
>
> Key: HADOOP-2543
> URL: https://issues.apache.org/jira/browse/HADOOP-2543
> Project: Hadoop
> Issue Type: New Feature
> Components: dfs
> Affects Versions: 0.15.1
> Reporter: Sanjay Radia
> Assignee: Hairong Kuang
> Fix For: 0.16.0
>
>
> In moving to 0.16, which will support permissions, a mode of no-permission
> checking has been proposed to allow smooth transition to using the new
> permissions feature.
> The idea is that at first 0.16 will be used for a period of time with
> permission checking off.
> Later after the admin has changed ownership and permissions of various files,
> the permission checking can be turned off.
> This Jira defines what the semantics are of the no-permission-checking mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
