Bug 10629 - include directive fails when referencing Parent Path within a WAR
Summary: include directive fails when referencing Parent Path within a WAR
Status: RESOLVED DUPLICATE of bug 13583
Alias: None
Product: Tomcat 4
Classification: Unclassified
Component: Jasper 2 (show other bugs)
Version: 4.1.8
Hardware: Other other
: P3 major with 5 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 11802 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-07-10 08:41 UTC by Andrew Conrad
Modified: 2004-11-16 19:05 UTC (History)
3 users (show)



Attachments
Test WAR to duplicate the problem (1.52 KB, application/octet-stream)
2002-07-10 08:42 UTC, Andrew Conrad
Details
Patch for WARDirContext.java to resolve relative path issues (1.46 KB, patch)
2002-07-13 21:29 UTC, Andrew Conrad
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Conrad 2002-07-10 08:41:08 UTC
using the include directive fails when referencing the Parent path when the 
Context is set directly to the WAR file, yet succeeds when accessing the 
unpacked WAR directories.

This Context fails:
<Context path="/ServerTest" docBase="ServerTest.war"
        debug="0" privileged="true" />

but expanding the war and setting this context succeeds
<Context path="/ServerTest" docBase="ServerTest"
        debug="0" privileged="true" />

the test files were setup as such: (the WAR will be attached)

/inc.htm
/testdir/DotDotInclude.jsp
where DotDotInclude.jsp has a tag
<%@ include file="../inc.htm"%>


Hacking at the source code for jasper2 revealed that when the call was made to 
JSPCompilationContext.getResourceAsStream(String res)
res = "/testdir/../inc.htm"
The returned java.io.InputStream was null if the WAR was the Context docBase, 
and not null if referencing the directory.
Comment 1 Andrew Conrad 2002-07-10 08:42:11 UTC
Created attachment 2301 [details]
Test WAR to duplicate the problem
Comment 2 Paul Landolt 2002-07-10 18:25:04 UTC
I believe it is also the case that the bug manifests itself with any relative 
path reference, not merely a reference to a parent path. For example, the 
directive:

<%@ include file="./inc.htm"%>

Will also generate a "not found" error
Comment 3 Andrew Conrad 2002-07-13 21:27:51 UTC
It seems that ZIP format accepts directory paths such as /dir/../testfile.htm 
as a valid entry and stores the file as so.  Assumming that is a correct 
implementation, the parent directory and current directory notation should be 
dealt with Prior to requesting the file from the ZipFile.

Since other DirContext's may handle relative paths, (FileDirContext does) I 
patched org.apache.naming.resources.WARDirContext.java, resolving the relative 
paths before retrieval.

--- WARDirContext.old	2002-07-13 06:04:37.000000000 -0400
+++ WARDirContext.java	2002-07-13 06:30:59.000000000 -0400
@@ -246,6 +246,7 @@
         throws NamingException {
         if (name.isEmpty())
             return this;
+        name = handleRelativePaths(name); //removes Dot and DotDot notation
         Entry entry = treeLookup(name);
         if (entry == null)
             throw new NamingException
@@ -772,6 +773,35 @@
 
     }
 
+		/**
+		* Handle Relative file path markers such as .. and .
+		* Assumes that the name will begin "/" and will maintain this
+		*/
+		protected static Name handleRelativePaths(Name BaseName)
+				throws NamingException {
+			boolean hasChanged = true;
+			Name name = BaseName.getSuffix(0); //creating a new 
name, so as not to modify the old
+			while(hasChanged) {
+				hasChanged = false;
+				for(int i = 0; i < name.size(); i++) {
+					//remove any Dot Dot notation, if it's 
not the root
+					if( name.get(i).equals("..") && i > 1) 
{  //will not handle the case "/.." . let current system handle situation
+						name.remove(i);
+						name.remove(i - 1);
+						hasChanged = true;
+						break; //start over
+					}
+
+					//removes any Single Dot notation
+					if( name.get(i).equals(".") ) {
+						name.remove(i);
+						hasChanged = true;
+						break; //start over
+					}
+				}
+			}
+			return name;
+		}
 
     /**
      * Constructs a tree of the entries contained in a WAR file.



--- file end ----







Comment 4 Andrew Conrad 2002-07-13 21:29:18 UTC
Created attachment 2346 [details]
Patch for WARDirContext.java to resolve relative path issues
Comment 5 Andrew Harris 2002-07-22 14:05:59 UTC
Fixing this bug is particularly important when using Tomcat with JBoss, as JBoss
currently (3.0.0) does not provide a way to unpack the WARs.
Comment 6 Remy Maucherat 2002-07-22 14:19:17 UTC
This should be resolved in Jasper (and a canonical path should be passed to the
getResource method IMO).
This should be fixed in Tomcat 4.1.8.

*** This bug has been marked as a duplicate of 10711 ***
Comment 7 Andrew Harris 2002-07-22 15:21:52 UTC
This bug has been marked as a duplicate of 10711, which has been marked as
RESOLVED FIXED; however it seems to me that the fix for 10711 only addresses the
issue of an included JSP file, not an HTML or text file. 

Isn't a change to getResourceAsStream and getResource needed? (Or to WARDirContext?)
Comment 8 Andrew Conrad 2002-07-24 08:59:00 UTC
Andrew Harris was correct in that the fix for 10711 did not fix the problem 
for includes of files with extensions other than *.jsp.


Here is a patch that solves the problem within the 
JspCompilationContext.java.  If the getResource method should already be 
recieving a canonical name, as Remy suggests, then maybe a utility class is 
needed for relative path resolution, instead of duplicating the canonicalURI 
method to multiple locations.


--- JspCompilationContext.old	2002-07-24 02:12:00.000000000 -0400
+++ JspCompilationContext.java	2002-07-24 04:18:17.000000000 -0400
@@ -227,12 +227,12 @@
      *         as an InputStream.
      */
     public java.io.InputStream getResourceAsStream(String res) {
-        return context.getResourceAsStream(res);
+        return context.getResourceAsStream(canonicalURI(res));
     }
 
 
     public URL getResource(String res) throws MalformedURLException {
-        return context.getResource(res);
+        return context.getResource(canonicalURI(res));
     }
 
     /** 
Comment 9 Remy Maucherat 2002-07-24 09:10:26 UTC
I've applied the patch.
Comment 10 Andrew Conrad 2002-08-18 19:11:57 UTC
*** Bug 11802 has been marked as a duplicate of this bug. ***
Comment 11 Ni Paikowsky 2002-11-06 13:27:09 UTC
This bug still exists in tomcat version - 4.1.12.
Comment 12 Remy Maucherat 2002-11-06 13:36:25 UTC
Don't reopen the same bug many times.

*** This bug has been marked as a duplicate of 13583 ***