[
https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273384#comment-16273384
]
Rushabh S Shah commented on HDFS-12873:
---------------------------------------
bq. By it worked as expected, do you mean it compressed the path to
/user/rushabhs/benchmarks/test2, or threw an exception?
By worked as expected, I meant it created {{/user/rushabhs/benchmarks/test2}}
directory.
But the normalization of {{..}} was done on the dfs client side.
Since you are not doing any client validation, namenode is handling the raw
path.
HDFS-5104 added the support to handle {{..}} in the path but exactly at 4th
index {{/.reserved/.inodes/<inodeid>/../}} (split by /)
Pre HDFS-5104, if the path contains {{..}} when it reaches namenode, it threw
{{InvalidPathException}}
But this patch introduced a bug where {{..}} can slip through.
{code:title=FsDirectory.java|borderStyle=solid}
byte[][]
org.apache.hadoop.hdfs.server.namenode.FSDirectory.resolveDotInodesPath(byte[][]
pathComponents, FSDirectory fsd) throws FileNotFoundException
...
...
// Handle single ".." for NFS lookup support.
if ((pathComponents.length > 4)
&& Arrays.equals(pathComponents[4], DOT_DOT)) {
INode parent = inode.getParent();
if (parent == null || parent.getId() == INodeId.ROOT_INODE_ID) {
// inode is root, or its parent is root.
return new byte[][]{INodeDirectory.ROOT_NAME};
}
return parent.getPathComponents();
}
{code}
According to above code snippet from HDFS-5104, it looks like that jira just
expected to have {{..}} at the 4th index of the path.
So the fix should be in {{DFSUtilClient#isValidName}} to throw
{{InvalidPathException}} if {{..}} is present and not at the 4th index.
> Creating a '..' directory is possible using inode paths
> -------------------------------------------------------
>
> Key: HDFS-12873
> URL: https://issues.apache.org/jira/browse/HDFS-12873
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs, namenode
> Affects Versions: 2.8.0
> Environment: Apache NameNode running in a Docker container on a
> Fedora 25 workstation.
> Reporter: Raeanne J Marks
>
> Start with a fresh deployment of HDFS.
> 1. Mkdirs '/x/y/z'
> 2. use GetFileInfo to get y's inode number
> 3. Mkdirs '/.reserved/.inodes/<y's inode number>/z/../foo'
> Expectation: The path in step 3 is rejected as invalid (exception thrown) OR
> foo would be created under y.
> Observation: This created a directory called '..' under z and 'foo' under
> that '..' directory instead of consolidating the path to '/x/y/foo' or
> throwing an exception. GetListing on '/.reserved/.inodes/<z's inode number>'
> shows '..', while GetListing on '/x/y' does not.
> Mkdirs INotify events were reported with the following paths, in order:
> /x
> /x/y
> /x/y/z
> /x/y/z/..
> /x/y/z/../foo
> I can also chain these dotdot directories and make them as deep as I want.
> Mkdirs works with the following paths appended to the inode path for
> directory y: '/z/../../../foo', '/z/../../../../../',
> '/z/../../../foo/bar/../..' etc, and it constructs all the '..' directories
> as if they weren't special names.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
