Created attachment 35993 [details] Patch We encounter weird errors with our webapp since tomcat 7.0.82 A change in org.apache.naming.resources.FileDirContext from Mark Thomas at 28.09.17 at 13:54 introduced the wrong behaviour due to difference in how constructors of java.io.File work. e.g.: File f = new File("/tmp/"); is not the same as: File fp = new File("/tmp"); File f = new File(f, "/"); Thus, the changed check in the validate-method can result in absPath = "/" and canPath = "" ...and the check for equals fails, although its the same path! I attached a patch to reverse the handling of absPath and canPath.
That patch, and the related patches, are part of the fix for security vulnerability CVE-2017-12617. You are going to need to provide a test case that demonstrates an incorrect behaviour before we are going to consider making any changes along the lines you request.
Created attachment 35994 [details] TestCase I attached a TestCase to demonstrate the behaviour.
Note: The provided test cases will fail on Windows. Note: testValidateFailure() only passes because it calls testValidateInternal(dummyFile, null) but it should be testValidateInternal(dummyFile, dummyFile) which currently fails. I don't see a way for this failure to occur in a standard directory deployment. There is code in FileDirContext that explicitly prevents this problem from occurring. It may be possible to trigger the issue with VirtualDirContext. I'll take a look. What are the steps to trigger this issue starting from a clean install of the latest Tomcat 7.0.x release? I suspect a fix, if required, is required somewhere other than where proposed but to be able be sure we need to be able to reproduce it.
I can't see a way to trigger this with VirtualDirContext either. Awaiting reproduction steps from a clean Tomcat install.
> Note: testValidateFailure() only passes because it calls > testValidateInternal(dummyFile, null) but it should be > testValidateInternal(dummyFile, dummyFile) which currently fails. Well, thats the whole point. It shouldn't pass. I didn't know that you prefer a failing test for the correct behaviour instead of a working test to demonstrate the wrong behaviour. > I can't see a way to trigger this with VirtualDirContext either. Well, I do! So let me show you: Compare the following lines of VirtualDirContext: 215 and 305 In the second one (part of the method "doLookup") the path variable is extended to have a trailing slash - as is should be! But in the other (part of method "file") it's not! You check for > name.startsWith(path + "/") but then do a > String res = name.substring(path.length()) which of course will result in "/" - which is then passed to > file = new File(resourcesDir, res); and this results in exactly the described behaviour! Do you really want me to implement a whole webapp to further demonstrate this obvious bug?
Fixed in 7.0.x for 7.0.90 onwards.