Discussion of fsck operation in the permissions regime
------------------------------------------------------
Key: HADOOP-2632
URL: https://issues.apache.org/jira/browse/HADOOP-2632
Project: Hadoop
Issue Type: Task
Components: dfs
Affects Versions: 0.16.0
Reporter: Robert Chansler
Assignee: Robert Chansler
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.
