[ 
https://issues.apache.org/jira/browse/HDFS-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545797#comment-16545797
 ] 

Wei-Chiu Chuang commented on HDFS-6600:
---------------------------------------

This is unfortunate. I am still able to reproduce this bug on a Hadoop 3 
cluster.

Interestingly, while -move doesn't work in such a case, -delete works.
If you look at the code,  -delete simply calls NameNodeRpc API as the current 
user
{code:title=NameNodeFsck#deleteCorruptedFile}
private void deleteCorruptedFile(String path) {
    try {
      namenode.getRpcServer().delete(path, true);
      LOG.info("Fsck: deleted corrupt file " + path);
    } catch (Exception e) {
      LOG.error("Fsck: error deleting corrupted file " + path, e);
      internalError = true;
    }
  }
{code}
whereas -move starts a dfs client and copy the file. Since NameNode APIs 
doesn't implement file copy, fsck has to start a client and copy the file 
explicitly. Why does it called '-move" when it actually does copy?

I am not quite sure if the attached patch is the right approach to fix the 
problem. Fsck doesn't check for super user permission by itself. So if you 
force fsck to run as login user (which has superuser perm), any user could run 
fsck and move the file to list+found.

> fsck -move fails in secured clusters.
> -------------------------------------
>
>                 Key: HDFS-6600
>                 URL: https://issues.apache.org/jira/browse/HDFS-6600
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: security, tools
>    Affects Versions: 2.4.0, 3.0.0-alpha1
>            Reporter: Chris Nauroth
>            Assignee: Krish Dey
>            Priority: Major
>              Labels: BB2015-05-TBR
>         Attachments: HDFS-6600.1.PATCH, HDFS-6600.2.patch
>
>
> In a secured cluster, running hdfs fsck -move fails.  When trying to move the 
> recovered blocks to lost+found, fsck tries to start using a DFSClient, but it 
> doesn't have the credentials to authenticate that client.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to