On 19/05/2017 15:25, Christopher Schultz wrote: > Mark, > > On 5/18/17 1:01 PM, Mark Thomas wrote: >> On 17/05/2017 14:32, Michael Heinen wrote: >>> I am currently migrating a web app from Tomcat 7.0.73 to 8.5.15. >>> An embedded Tomcat is used on development systems. >>> >>> The web-inf/lib folder of the application contains a jar with a >>> SAXParserFactory implementation. This SAXParserFactory is now >>> used with TC 8.5 by the WebXmlParser in order to parse the >>> web.xml (and fails unfortunately). The ServiceLoader finds the >>> jar because the ParallelWebappClassLoader is used for the >>> lookup. >>> >>> TC 7.0.73 uses the sun.misc.Launcher$AppClassLoader and does >>> therefore not use the jar under web-inf\lib. It creates the >>> webXml Digester in the init() phase of the stanrardContext. TC >>> 8.5 does this in the startInternal() phase where the >>> ParallelWebappClassLoader is instantiated and bound to the >>> current thread. >>> >>> Specifying "javax.xml.parsers.SAXParserFactory" as VM param >>> solves the issue of course. > >> I think this is the fix that triggered this: >> https://svn.apache.org/viewvc?view=revision&revision=1731216 > >>> My question: Is this behaviour expected? > >> It looks like an unintended side-effect of the change. > >>> Should Tomcat use libraries of the web app for the startup of a >>> context, here for web-xml parsing? > >> The change has been in place for over a year and this is the first >> problem we have seen. I'm curious, what exactly was the problem you >> saw? > >> I'd probably lean towards fixing this on the grounds that you want >> to parsing of web.xml to be deterministic rather than dependent on >> what may, or may not, be included in the app. > >> What do others think? > > +1 > > Also, for an untrusted application (admittedly a minority use case), > having Tomcat parse the app-provided XML with an application-provided > XML parser might have security implications.
I don't believe it does in this case. The file being parsed is web.xml which is application provided anyway so any manipulation a malicious app could do via the parser could just be done directly in web.xml. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
