hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Chansler (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (HADOOP-2632) Discussion of fsck operation in the permissions regime
Date Thu, 14 Aug 2008 22:35:44 GMT

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


Mime
View raw message