[jira] [Comment Edited] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273470#comment-16273470 ] Raeanne J Marks edited comment on HDFS-12873 at 11/30/17 9:38 PM: -- Oops, not very descriptive. I meant if you try to get the file status of a file using a path containing {{..}} after the 4th index, but I was recalling something different and was incorrect. Please disregard that comment. What I mentioned about ignoring anything after the {{..}} in the 4th index is true though. For example, getFileStatus on {{'/.reserved/.inodes//../I/don't/exist}} would return y's parent's info ({{x}}) - it just throws away {{I/don't/exist}}. was (Author: raemarks): Oops, not very descriptive. I meant if you try to get the file status of a file using a path containing {{..}} after the 4th index, but I was recalling something different and was incorrect. Please disregard that comment. What I mentioned about ignoring anything after the {{..}} in the 4th index is true though. For example, {{'/.reserved/.inodes//../I/don't/exist}} would return y's parent's inode number ({{x}}) - it just throws away {{I/don't/exist}}. > 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//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/' > 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
[jira] [Comment Edited] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273470#comment-16273470 ] Raeanne J Marks edited comment on HDFS-12873 at 11/30/17 9:29 PM: -- Oops, not very descriptive. I meant if you try to get the file status of a file using a path containing {{..}} after the 4th index, but I was recalling something different and was incorrect. Please disregard that comment. What I mentioned about ignoring anything after the {{..}} in the 4th index is true though. For example, {{'/.reserved/.inodes//../I/don't/exist}} would return y's parent's inode number ({{x}}) - it just throws away {{I/don't/exist}}. was (Author: raemarks): Oops, not very descriptive. I meant if you try to get the file status of a file using a path containing {{..}} after the 4th index, but I was recalling something different and was incorrect. Please disregard that comment. What I mentioned about ignoring anything after the {{..}} in the 4th index is true though. For example, {{'/.reserved/.inodes//../I/don't/exist}} would return y's parent's inode number (x) - it just throws away {{I/don't/exist}}. > 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//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/' > 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
[jira] [Commented] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273470#comment-16273470 ] Raeanne J Marks commented on HDFS-12873: Oops, not very descriptive. I meant if you try to get the file status of a file using a path containing {{..}} after the 4th index, but I was recalling something different and was incorrect. Please disregard that comment. What I mentioned about ignoring anything after the {{..}} in the 4th index is true though. For example, {{'/.reserved/.inodes//../I/don't/exist}} would return y's parent's inode number (x) - it just throws away {{I/don't/exist}}. > 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//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/' > 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
[jira] [Commented] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273406#comment-16273406 ] Raeanne J Marks commented on HDFS-12873: I've been poking this code a lot lately and it seems to only support the {{..}} if it's directly after the inode number, so yes only at the 4th index. If there is {{..}} after the 4th index and the 4th index is not {{..}}, it fails. Also, the NameNode appears to silently throw away any path components following {{/.reserved/.inodes//..}} instead of failing, which could be misleading. > 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//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/' > 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
[jira] [Commented] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ 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 >
[jira] [Comment Edited] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273122#comment-16273122 ] Raeanne J Marks edited comment on HDFS-12873 at 11/30/17 6:33 PM: -- [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {code} # hadoop version Hadoop 2.8.0 {code} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {code} >> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, >> auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } >> bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 } {code} was (Author: raemarks): [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {code} # hadoop version Hadoop 2.8.0 {code} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {code} >> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, >> auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 } {code} > 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//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 > throwin
[jira] [Comment Edited] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273122#comment-16273122 ] Raeanne J Marks edited comment on HDFS-12873 at 11/30/17 6:31 PM: -- [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {code} # hadoop version Hadoop 2.8.0 {code} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {{ >> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 } }} was (Author: raemarks): [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {{# hadoop version Hadoop 2.8.0}} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {{ >> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 } }} > 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//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 '/.reserv
[jira] [Comment Edited] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273122#comment-16273122 ] Raeanne J Marks edited comment on HDFS-12873 at 11/30/17 6:31 PM: -- [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {code} # hadoop version Hadoop 2.8.0 {code} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {code} >> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, >> auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 } {code} was (Author: raemarks): [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {code} # hadoop version Hadoop 2.8.0 {code} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {{ >> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 } }} > 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//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.
[jira] [Comment Edited] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273122#comment-16273122 ] Raeanne J Marks edited comment on HDFS-12873 at 11/30/17 6:30 PM: -- [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {{# hadoop version Hadoop 2.8.0}} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {{ >> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 } }} was (Author: raemarks): [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {{# hadoop version Hadoop 2.8.0}} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {{>> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 }}} > 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//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/'
[jira] [Commented] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273122#comment-16273122 ] Raeanne J Marks commented on HDFS-12873: [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {{# hadoop version Hadoop 2.8.0}} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {{>> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 }}} > 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//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/' > 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
[jira] [Comment Edited] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273122#comment-16273122 ] Raeanne J Marks edited comment on HDFS-12873 at 11/30/17 6:29 PM: -- [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {{# hadoop version Hadoop 2.8.0}} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {{>> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 }}} was (Author: raemarks): [~shahrs87] By it worked as expected, do you mean it compressed the path to {{/user/rushabhs/benchmarks/test2}}, or threw an exception? I can confirm I'm seeing this in {{2.8.0}}: {{# hadoop version Hadoop 2.8.0}} I am using a snakebite-like hadoop client. It does not perform any client-side path manipulation/validation - it relies on the NameNode to properly handle/report unsupported path formats. Here is my script: {{>> client = pydoofus.namenode.v9.Client('172.18.0.2', 8020, auth={'effective_user': 'hdfs'}) >> print client.mkdirs('/x/y/z', 0777, create_parent=True) True >> file_status = client.get_file_info('/x/y') >> print file_status FileStatus { file_type: DIRECTORY path: length: 0 permission: Permission { mode: 0777 } owner: hdfs group: supergroup modification_time: 1512066397076 access_time: 0 symlink: replication: 0 block_size: 0 locations: None file_id: 16580 num_children: 1 } bad_path = '/.reserved/.inodes/' + str(file_status.file_id) + '/z/../foo' >> print client.mkdirs(bad_path, 0777, create_parent=True) True >> print client.get_listing('/x/y/z') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'..', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16582L, num_children=1)] remaining: 0 } >> print client.get_listing('/x/y/z/..') DirectoryListing { entries: [FileStatus(file_type='DIRECTORY', path=u'foo', length=0L, permission=Permission(mode=0777), owner=u'hdfs', group=u'supergroup', modification_time=1512066397083, access_time=0, symlink='', replication=0, block_size=0L, locations=None, file_id=16583L, num_children=0)] remaining: 0 }}} > 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//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/' >
[jira] [Updated] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raeanne J Marks updated HDFS-12873: --- Description: 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//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/' 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. was: 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//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/` 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. > 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//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/' > 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
[jira] [Updated] (HDFS-12873) Creating a '..' directory is possible using inode paths
[ https://issues.apache.org/jira/browse/HDFS-12873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raeanne J Marks updated HDFS-12873: --- Description: 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//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/` 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. was: 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//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/' 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. > 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//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/ 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
[jira] [Created] (HDFS-12873) Creating a '..' directory is possible using inode paths
Raeanne J Marks created HDFS-12873: -- Summary: 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//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/' 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