[
https://issues.apache.org/jira/browse/HADOOP-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Chansler resolved HADOOP-2632.
-------------------------------------
Resolution: Fixed
Fix Version/s: 0.18.0
No outstanding problems.
> Discussion of fsck operation in the permissions regime
> ------------------------------------------------------
>
> Key: HADOOP-2632
> URL: https://issues.apache.org/jira/browse/HADOOP-2632
> Project: Hadoop Core
> Issue Type: Task
> Components: dfs
> Affects Versions: 0.16.0
> Reporter: Robert Chansler
> Assignee: Robert Chansler
> Fix For: 0.18.0
>
>
> Proposal: In 0.16, with permission checking enabled, fsck will just work
> regardless of permission settings.
> The normal operation of fsck can reveal information about the name system
> that would otherwise be unavailable to a user via other commands that would
> be subject to permission checking. While not best, this situation seems
> tolerable for 0.16.
> 1. It not certain what permission checking should be done, other than
> perhaps just restricting fsck to the superuser.
> 2. The information revealed is not too privileged.
> 3. The mischievous user has better things to do.
> 4. fsck does not fit with either of the existing models for permission
> checking.
> fsck is implemented as HTTP GET of a well-known URL. As such, the first
> thought is that it should operate with the permissions of web UI client. In
> 0.16, the web UI client is presumed to have the identity of some
> cluster-configured user. If the cluster-configured user is the superuser, web
> UI clients can browse the contents of any file. If the user is any other
> identity, the user would not have full access to the name space necessary for
> fsck to operate unless every directory had mode a+r. The alternative is to
> treat fsck according to the rules of other administrative commands. At
> present, fsck does no RPC requests, and so there is no option to apply the
> permission checking rules used by other commands.
> If it is important to change 0.16 so that fsck checked user identity, an
> implementation would have to use a new RPC to obtain a ticket that authorized
> access to the fsck URL. The ticket would be passed as a parameter to HTTP
> GET. The implementation of fsck would check the the proffered ticket was
> valid before traversing the name space.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
