[jira] Resolved: (HADOOP-2632) Discussion of fsck operation in the permissions regime

["Robert Chansler (JIRA)" <ji...@apache.org>]

     [ 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.