[
https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273353#comment-16273353
]
Raeanne J Marks commented on HDFS-12873:
----------------------------------------
Interestingly, this is not reproducible with WebHDFS if WebHDFS is used to make
that bad path:
{code}
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}' -X PUT
'http://172.18.0.2:50070/webhdfs/v1/x/y/z?op=MKDIRS&user.name=hdfs'
{"boolean":true}200⏎
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}'
'http://172.18.0.2:50070/webhdfs/v1/x/y?op=GETFILESTATUS'
{"FileStatus":{"accessTime":0,"blockSize":0,"childrenNum":1,"fileId":16587,"group":"supergroup","length":0,"modificationTime":1512068214198,"owner":"hdfs","pathSuffix":"","permission":"755","replication":0,"storagePolicy":0,"type":"DIRECTORY"}}200⏎
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}' -X PUT
'http://172.18.0.2:50070/webhdfs/v1/.reserved/.inodes/16587/z/../foo?op=MKDIRS&user.name=hdfs'
{"boolean":true}200⏎
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}'
'http://172.18.0.2:50070/webhdfs/v1/x/y/z?op=LISTSTATUS'
{"FileStatuses":{"FileStatus":[]}}200⏎
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}'
'http://172.18.0.2:50070/webhdfs/v1/x/y?op=LISTSTATUS'
{"FileStatuses":{"FileStatus":[
{"accessTime":0,"blockSize":0,"childrenNum":0,"fileId":16589,"group":"supergroup","length":0,"modificationTime":1512068246054,"owner":"hdfs","pathSuffix":"foo","permission":"755","replication":0,"storagePolicy":0,"type":"DIRECTORY"},
{"accessTime":0,"blockSize":0,"childrenNum":0,"fileId":16588,"group":"supergroup","length":0,"modificationTime":1512068214198,"owner":"hdfs","pathSuffix":"z","permission":"755","replication":0,"storagePolicy":0,"type":"DIRECTORY"}
]}}200⏎
{code}
However, if I run the problematic {{Mkdirs}} with our snakebite-like client
then try to list with WebHDFS, the problem is once again exposed:
{code}
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}'
'http://172.18.0.2:50070/webhdfs/v1/x/y?op=LISTSTATUS'
{"FileStatuses":{"FileStatus":[
{"accessTime":0,"blockSize":0,"childrenNum":1,"fileId":16592,"group":"supergroup","length":0,"modificationTime":1512073040206,"owner":"hdfs","pathSuffix":"z","permission":"777","replication":0,"storagePolicy":0,"type":"DIRECTORY"}
]}}200⏎
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}'
'http://172.18.0.2:50070/webhdfs/v1/x/y/z?op=LISTSTATUS'
{"FileStatuses":{"FileStatus":[
{"accessTime":0,"blockSize":0,"childrenNum":1,"fileId":16593,"group":"supergroup","length":0,"modificationTime":1512073040207,"owner":"hdfs","pathSuffix":"..","permission":"777","replication":0,"storagePolicy":0,"type":"DIRECTORY"}
]}}200⏎
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}'
'http://172.18.0.2:50070/webhdfs/v1/x/y/z/..?op=LISTSTATUS'
{"FileStatuses":{"FileStatus":[
{"accessTime":0,"blockSize":0,"childrenNum":1,"fileId":16592,"group":"supergroup","length":0,"modificationTime":1512073040206,"owner":"hdfs","pathSuffix":"z","permission":"777","replication":0,"storagePolicy":0,"type":"DIRECTORY"}
]}}200⏎
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}'
'http://172.18.0.2:50070/webhdfs/v1/x/y/z/../foo?op=GETFILESTATUS'
{"RemoteException":{"exception":"FileNotFoundException","javaClassName":"java.io.FileNotFoundException","message":"File
does not exist: /x/y/foo"}}404⏎
rmarks@rmarks-wkstn ~> curl -sS -L -w '%{http_code}'
'http://172.18.0.2:50070/webhdfs/v1/.reserved/.inodes/16593?op=LISTSTATUS'
{"FileStatuses":{"FileStatus":[
{"accessTime":0,"blockSize":0,"childrenNum":0,"fileId":16594,"group":"supergroup","length":0,"modificationTime":1512073040207,"owner":"hdfs","pathSuffix":"foo","permission":"777","replication":0,"storagePolicy":0,"type":"DIRECTORY"}
]}}200⏎
{code}
This shows there is no {{foo}} under {{y}}, {{..}} is visible under {{z}}, and
{{foo}} is inaccessible except by using an inode path to access {{/x/y/z/..}}.
> 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: [email protected]
For additional commands, e-mail: [email protected]
