tahoe-lafs/trac-2024-07-25

disallow slashes in webish-UI childnames #75

New issue

Closed

opened 2007-07-01 04:36:06 +00:00 by nejucomo · 3 comments

nejucomo commented

2007-07-01 04:36:06 +00:00

Owner

I entered a non-existent local-filesystem, linux-style, absolute path into the "Name to place incoming directory" field.

Then pasted the read/write URI of my vdrive's root into the "URI of Shared Directory". I have no idea if these are valid values because I'm not sure what this operation represents (see ticket #74).

After clicking "Mount Shared Directory", a new entry is added to the web ui. When I click on the link (whose text is the non-existent path given above), I get a bare page with "Sorry, but I couldn't find the object you requested.".

I entered a non-existent local-filesystem, linux-style, absolute path into the "Name to place incoming directory" field. Then pasted the read/write URI of my vdrive's root into the "URI of Shared Directory". I have no idea if these are valid values because I'm not sure what this operation represents (see ticket #74). After clicking "Mount Shared Directory", a new entry is added to the web ui. When I click on the link (whose text is the non-existent path given above), I get a bare page with "Sorry, but I couldn't find the object you requested.".

tahoe-lafs added the

labels 2007-07-01 04:36:06 +00:00

warner commented

2007-07-02 19:13:26 +00:00

Author

Owner

Do you mean that you typed in something like "foo/bar/newdirectory" into that Name field?

So, most of tahoe's filesystem layer treats pathnames as lists of strings. This means that, in most places, filenames and directorynames can contain anything: slashes, newlines, NUL bytes, unicode, whatever.

However, at the top-most layer, there is a convenience method that accepts a single string of slash-separated pathname components. This makes it easier to write tests and user code. It is at this point that a no-slashes-in-filenames rule appears.

In addition, the HTTP specifications treat slashes specially, so the webish.py front-end follows suit and splits the URL into pathname components before doing the lookup. webish.py doesn't use the convenience function, rather each URL component is used in a series of resource.getChild() calls to traverse a path downwards through the filesystem to the target directory.

However, the webish.py code that lets you add things to the filesystem isn't enforcing this no-slashes rule. So what probably happened is that you added a child named 'foo/bar/newdir', then the mount-shared-directory operation redirected you to parent/foo/bar/newdir, which splits into ['parent', 'foo', 'bar', 'newdir'] and fails to hit the actual child which was ['parent', 'foo/bar/newdir']. If you do a list on the parent directory, you should see the foo/bar/newdir child, but you won't be able to follow that link any better than the redirect.

The fix for this should probably be a check in the add-child webish.py operations to reject childnames with slashes in them. We should make a decision about whether this rule should be enforced lower down as well: I can vaguely imagine applications where you want to allow slashes in filenames, but I can also imagine that rejecting them outright will let us avoid this sort of problem altogether. Are there any common filesystems (by which I mean windows) which allow slashes in pathnames?

Do you mean that you typed in something like "foo/bar/newdirectory" into that Name field? So, most of tahoe's filesystem layer treats pathnames as lists of strings. This means that, in most places, filenames and directorynames can contain *anything*: slashes, newlines, NUL bytes, unicode, whatever. However, at the top-most layer, there is a convenience method that accepts a single string of slash-separated pathname components. This makes it easier to write tests and user code. It is at this point that a no-slashes-in-filenames rule appears. In addition, the HTTP specifications treat slashes specially, so the webish.py front-end follows suit and splits the URL into pathname components before doing the lookup. webish.py doesn't use the convenience function, rather each URL component is used in a series of resource.getChild() calls to traverse a path downwards through the filesystem to the target directory. However, the webish.py code that lets you add things to the filesystem isn't enforcing this no-slashes rule. So what probably happened is that you added a child named 'foo/bar/newdir', then the mount-shared-directory operation redirected you to parent/foo/bar/newdir, which splits into ['parent', 'foo', 'bar', 'newdir'] and fails to hit the actual child which was ['parent', 'foo/bar/newdir']. If you do a list on the parent directory, you should see the foo/bar/newdir child, but you won't be able to follow that link any better than the redirect. The fix for this should probably be a check in the add-child webish.py operations to reject childnames with slashes in them. We should make a decision about whether this rule should be enforced lower down as well: I can vaguely imagine applications where you want to allow slashes in filenames, but I can also imagine that rejecting them outright will let us avoid this sort of problem altogether. Are there any common filesystems (by which I mean windows) which allow slashes in pathnames?

tahoe-lafs changed title from ~~Directory contains entry pointing to "Sorry, but I couldn't find the object you requested." page.~~ to disallow slashes in webish-UI childnames

2007-07-02 19:29:23 +00:00

warner commented

2007-07-16 19:08:34 +00:00

Author

Owner

Hm, we need to do the same thing for renames. I'll talk to rob about that, since we need some tests anyways. I'm going to leave this ticket open pending that fix.

Done, in changeset:f207f4a199452da9. The only place where we do the check is in the POST operation that adds a file (either by contents or by uri), and we only check the name= argument, since that's the one place where you can provide a vdrive filename that isn't already inside a slash-hostile URL. Hm, we need to do the same thing for renames. I'll talk to rob about that, since we need some tests anyways. I'm going to leave this ticket open pending that fix.

warner commented

2007-07-17 00:42:21 +00:00

Author

Owner

rob just pushed changeset:920fed7f2aeb4f6e, which checks for slashes in rename operations, so now I think we can close this one.

tahoe-lafs added the

fixed

label 2007-07-17 00:42:21 +00:00

warner closed this issue

2007-07-17 00:42:21 +00:00