Filenames containing slash

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a filename containing a slash. For instance, go to an existing file, 
say foo.java and rename it to something like f/oo.java
2. Get the URI of the file from the containing JSON object
3. Perform a DELETE request o the file using the URI from step 2.

What is the expected output? What do you see instead?
The expected output would be to remove the file. I get NOT FOUND instead.

What version of the product are you using? On what operating system?
Access to the API from Java clients.

Please provide any additional information below.

Original issue reported on code.google.com by louri...@gmail.com on 24 Sep 2010 at 1:54

[GoogleCodeExporter]

There was a security issue (CVE-2007-0450) that has led to Tomcat not allowing 
encoded slashes to reach the application, therefore causing gss to look for 
different paths than those requested. There is a configuration flag 
(ALLOW_ENCODED_SLASH) that could revert that behavior, but I don't think that 
reverting security patches for dubious use cases is prudent. You can find out 
more in the following links:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0450
https://www.covalent.net/download/patch2.0/README-ers-3.1.0-patch-tomcat-2007031
5.txt
http://tomcat.apache.org/tomcat-5.5-doc/config/systemprops.html

Original comment by past...@gmail.com on 28 Sep 2010 at 12:02

• Changed state: WontFix

[GoogleCodeExporter]

Then what is going to happen to those files that are entering Pithos with 
slashes in them? Currently there is no way to remove them; in fact there is no 
way to see them anymore, unless you use directly API calls. So the problem is 
that you end up with these kind of zombie files that you cannot really get rid 
of. 

Also, the situation with Tomcat you are mentioning is not followed consistently 
in Pithos, otherwise I would not expect the file to be in Pithos in the first 
place. Creating the file is not a problem; seeing it and removing it is.

Original comment by louri...@gmail.com on 28 Sep 2010 at 12:19

[GoogleCodeExporter]

You're right, I hadn't considered this. I'm reopening the issue to fix the 
service to reject creation and renaming of such files and folders. We'll have 
to do some manual fixes in the DB for the files and folders created so far. 
Something like an SQL update that changes "foo/bar" to "foo-bar" should be 
appropriate.

Original comment by past...@gmail.com on 28 Sep 2010 at 1:17

• Changed state: Started

[GoogleCodeExporter]

Original comment by past...@gmail.com on 1 Oct 2010 at 10:04

• Added labels: Milestone-1.2

[GoogleCodeExporter]

Revision:  0952a64ae3  
Revision:  e90337bcca  
Revision:  8746b05052  
Revision:  6f0d7b746d

With the above revision the creation or the update of a resource (i.e file or 
folder) is not allowed. A note is displayed in the creation or the update of a 
resource that informs the users that slashes in the resource names is not 
permitted. The server code has also been updated to handle request with 
unaccepted resource names.

Original comment by akaprave...@gmail.com on 8 Oct 2010 at 7:24

[GoogleCodeExporter]

More fixes with the following
Revision:  3f5bf1b7b6  
Revision:  d2b982875b  

Original comment by akaprave...@gmail.com on 11 Oct 2010 at 10:50

[GoogleCodeExporter]

Original comment by past...@gmail.com on 11 Oct 2010 at 12:14

• Changed state: Verified