[Bug 56180] New: Bugfix 55943 changed backward compatibility in classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=56180
Bug ID: 56180
Summary: Bugfix 55943 changed backward compatibility in
classloading
Product: Tomcat 7
Version: 7.0.52
Hardware: PC
OS: Linux
Status: NEW
Severity: regression
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: ksms...@gmail.com
Between Tomcat 7.0.50 and Tomcat 7.0.52 changed logic of class loading which
may prevent to protect against CVE-2014-0050
My usecase:
1. I have
jcl-over-slf4j-1.7.5.jar
jul-to-slf4j.jar
log4j-over-slf4j-1.7.5.jar
logback-classic.jar
logback-core.jar
slf4j-api.jar
in Tomcat lib folder.
2. With help of setenv.sh I've add this jars to classpath
export
CLASSPATH="${CATALINA_HOME}/conf/:${CATALINA_HOME}/lib/jul-to-slf4j.jar:${CATALINA_HOME}/lib/slf4j-api.jar:${CATALINA_HOME}/lib/logback-classic.jar:${CATALINA_HOME}/lib/logback-core.jar:${CATALINA_HOME}/lib/mail.jar:${JAVA_HOME}/lib/tools.jar"
3. After update to tomcat 7.0.52 I've got
Caused by: java.lang.LinkageError: loader constraint violation: when resolving
method
"org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;"
the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of
the current class, org/slf4j/LoggerFactory, and the class loader (instance of
sun/misc/Launcher$AppClassLoader) for resolved class,
org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type
LoggerFactory; used in the signature
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:299)
~[slf4j-api.jar:1.7.5]
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:269)
~[slf4j-api.jar:1.7.5]
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)
~[slf4j-api.jar:1.7.5]
at com.codenvy.inject.ModuleScanner.(ModuleScanner.java:36)
~[na:na]
at java.lang.Class.forName0(Native Method) ~[na:1.7.0_51]
at java.lang.Class.forName(Class.java:270) ~[na:1.7.0_51]
at
org.apache.catalina.startup.WebappServiceLoader.loadServices(WebappServiceLoader.java:187)
~[catalina.jar:7.0.52]
at
org.apache.catalina.startup.WebappServiceLoader.load(WebappServiceLoader.java:152)
~[catalina.jar:7.0.52]
at
org.apache.catalina.startup.ContextConfig.processServletContainerInitializers(ContextConfig.java:1543)
~[ca
Note. See comment in issue. I assume he have the same problem
https://issues.apache.org/bugzilla/show_bug.cgi?id=55943#c8
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56181] New: RemoteIpValve & RemoteIpFilter: HttpServletRequest.getRemoteHost() returns IP instead of hostname with enableLookups=true and x-forwarded-for header
https://issues.apache.org/bugzilla/show_bug.cgi?id=56181
Bug ID: 56181
Summary: RemoteIpValve & RemoteIpFilter:
HttpServletRequest.getRemoteHost() returns IP instead
of hostname with enableLookups=true and
x-forwarded-for header
Product: Tomcat 7
Version: 7.0.52
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: yann...@gmail.com
When clients connect to Tomcat through a proxy or load balancer that adds a
remoteIpHeader (eg. "x-forwarded-for") and the attribute "enableLookups" is set
to "true", the expected behavior is that hostname of the clients is resolved by
Tomcat.
However it is not, if the method getRemoteHost() is called on a
HttpServletRequest object, the IP is always returned, not the hostname.
In the classes org.apache.catalina.valves.RemoteIpValve and
org.apache.catalina.filters.RemoteIpFilter we see that the IP is set to the
Hostname field without any option to do the reverse DNS lookup:
request.setRemoteAddr(remoteIp);
request.setRemoteHost(remoteIp);
Instead the pseudo code could be something like:
request.setRemoteAddr(remoteIp);
if(enableRemoteIpLookups == true){
request.setRemoteHost(InetAddress.getByName(remoteIp).getHostName());
}
Perhaps, instead of using "enableLookups" to indicate the reverse DNS lookup
wants to be done for requests passing through a proxy it should be better to
have a new Tomcat attribute for this (like enableRemoteIpLookups), because
perhaps you do not want to lookups of the proxies IP but just the remoteIp
(x-forwarded-for).
Note, this issue applies also to Tomcat 8.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56180] Bugfix 55943 changed backward compatibility in classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=56180 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mark Thomas --- See this thread for a full discussion of this topic: http://markmail.org/thread/mid36pgk7nckp2rr It looks like you should be adding those JARs to the endorsed dir rather than to the class path. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56179] ParseException for EL expression "${((test == true))}"
https://issues.apache.org/bugzilla/show_bug.cgi?id=56179 Holger Stenzhorn changed: What|Removed |Added CC||holger.stenzh...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56181] RemoteIpValve & RemoteIpFilter: HttpServletRequest.getRemoteHost() returns IP instead of hostname with enableLookups=true and x-forwarded-for header
https://issues.apache.org/bugzilla/show_bug.cgi?id=56181 Konstantin Kolinko changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Konstantin Kolinko --- For reference - discussion thread on the users list (Feb 20) http://tomcat.markmail.org/thread/2c4jo2ryqv74zgpp Changing severity to 'enhancement'. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56180] Bugfix 55943 changed backward compatibility in classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=56180
--- Comment #2 from Konstantin Kolinko ---
(In reply to Sergey Kabashnyuk from comment #0)
> 2. With help of setenv.sh I've add this jars to classpath
> export
> CLASSPATH="${CATALINA_HOME}/conf/:${CATALINA_HOME}/lib/jul-to-slf4j.jar:
> ${CATALINA_HOME}/lib/slf4j-api.jar:${CATALINA_HOME}/lib/logback-classic.jar:
> ${CATALINA_HOME}/lib/logback-core.jar:${CATALINA_HOME}/lib/mail.jar:
> ${JAVA_HOME}/lib/tools.jar"
>
For starters, move the mentioned libraries from ${CATALINA_HOME}/lib to
somewhere else (so that they are not present twice in System and Common
classloaders)
and make sure that your web application does not have another (third) copy of
them.
>From security risks point of view, you would better avoid having the whole
"conf" on the classpath either.
http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jasper Improvements
On Jun 26, 2013, at 05:44:23 GMT Jeremy Boynes wrote: > I have been thinking about improvements to Jasper as well around better > support for Servlet > 3.0 concepts. One area would be decoupling it from Tomcat, bootstrapping > using an SCI as hinted > in ContextConfig. I'd also be interested in improving the Ant task as well, > such as support > for pre-compiling a separate package that would be treated as a web fragment > (including web.xml-less > pre-compilation, generating a web-fragment.xml rather than a web.xml snippet > or potentially > eliminating the XML entirely if the generated code can be annotated with > @WebServlet). Jeremy et al, The Jetty project has been considering switching to directly consume the apache version of Jasper JSP. However, there are some tomcat dependencies in jasper that means we cannot directly consume the jar produced by the apache project.We had assumed that there would be little interest here to make jasper separable so we had begun our own effort at github. However, when I gave a heads up to priv...@tomcat.apache.org, I was pointed at Jeremy's email. So if there is some interest here, then it would definitely be better to do this within apache rather than via an intermediate repository. What we have done so far is to create a github project at github: https://github.com/jetty-project/jasper-jsp. This project mounts the tomcat github repo as a subtree and removes everything that is not el, jasper or a used utility. We've then changed a few hard tomcat dependencies to produce a container neutral version of jasper, which we then consume and specialise within a build of the jetty project (not yet at eclipse). We have this working at the moment, but have not yet done any releases, so there are no indelible maven artefacts yet. Nor have we done the IP clearance work to officially consume such an artefact within the eclipse project. The changes that we made to make jasper neutral were: - Modified JuliLog LogFactory to use a ServiceLoader to find an implementation of Log. Within the jetty project we add an impl of the Juli Log that logs to the jetty log and we set that as a service in our own jars META-INF. Note that judging by some of the comments in the classes, there is not much desire to make logging discoverable? - We have replaced the InstanceManager with a pretty simple non-container version. It does not do post construct or pre destroy, but don't think these are needed for Jasper. I guess rather than replace the top level InstanceManager, it would be better to have a Jasper Instance manager that could be instantiated as the container specific version, perhaps also with a ServiceLoader? - We changed the jasper ServletContainerInitialiser to allow some pluggability of the scanner and we turned off ServiceLoader for it so that we can provide our own extension of it. - We made the Tld scanning check for a prescanned list so that we can do the TLD discovery in our own scanning (rather than do another scan) and push those into jasper. A neutral version of Jasper could make scanning container specific and then most of the dependencies on tomcat utils could be removed. - We would also like to add the META-INF magic to make the resulting jars more OSGi consumable. As a project, Jetty has no desire to fork jasper. Rather we just want to re-bundle it in a way that can be consumed by the jetty project at eclipse and to use our own sanning/discovery/configuration mechanisms. We wish to be bug for bug compatible and if we did find/fix a bug, our preference would be to contribute back to apache. Also happy to contribute back changes to improve start time (eg by avoiding duplicate jar scans). We totally understand that making jasper consumable by jetty will not be a high priority for the tomcat project and that even minor changes to jar packaging can be disruptive. However, if it is desirable for other reasons, then we'd certainly be keen to lend a hand and I think most(all?) of our committers are already apache committers on some project or other. Anyway, we'll hold off making any indelible maven artefacts from our github project for a while, so that if something does happen within apache we can erase what we have done already. If there is interest here, then we could prepare a git pull request of our changes (against the apache github clone), or would we need to remember our svn and submit a diff against that? cheers
Re: Jasper Improvements
On Jun 26, 2013, at 05:44:23 GMT Jeremy Boynes wrote: > I have been thinking about improvements to Jasper as well around better > support for Servlet > 3.0 concepts. One area would be decoupling it from Tomcat, bootstrapping > using an SCI as hinted > in ContextConfig. I'd also be interested in improving the Ant task as well, > such as support > for pre-compiling a separate package that would be treated as a web fragment > (including web.xml-less > pre-compilation, generating a web-fragment.xml rather than a web.xml snippet > or potentially > eliminating the XML entirely if the generated code can be annotated with > @WebServlet). Jeremy et al, The Jetty project has been considering switching to directly consume the apache version of Jasper JSP. However, there are some tomcat dependencies in jasper that means we cannot directly consume the jar produced by the apache project.We had assumed that there would be little interest here to make jasper separable so we had begun our own effort at github. However, when I gave a heads up to priv...@tomcat.apache.org, I was pointed at Jeremy's email. So if there is some interest here, then it would definitely be better to do this within apache rather than via an intermediate repository. What we have done so far is to create a github project at github: https://github.com/jetty-project/jasper-jsp. This project mounts the tomcat github repo as a subtree and removes everything that is not el, jasper or a used utility. We've then changed a few hard tomcat dependencies to produce a container neutral version of jasper, which we then consume and specialise within a build of the jetty project (not yet at eclipse). We have this working at the moment, but have not yet done any releases, so there are no indelible maven artefacts yet. Nor have we done the IP clearance work to officially consume such an artefact within the eclipse project. The changes that we made to make jasper neutral were: - Modified JuliLog LogFactory to use a ServiceLoader to find an implementation of Log. Within the jetty project we add an impl of the Juli Log that logs to the jetty log and we set that as a service in our own jars META-INF. Note that judging by some of the comments in the classes, there is not much desire to make logging discoverable? - We have replaced the InstanceManager with a pretty simple non-container version. It does not do post construct or pre destroy, but don't think these are needed for Jasper. I guess rather than replace the top level InstanceManager, it would be better to have a Jasper Instance manager that could be instantiated as the container specific version, perhaps also with a ServiceLoader? - We changed the jasper ServletContainerInitialiser to allow some pluggability of the scanner and we turned off ServiceLoader for it so that we can provide our own extension of it. - We made the Tld scanning check for a prescanned list so that we can do the TLD discovery in our own scanning (rather than do another scan) and push those into jasper. A neutral version of Jasper could make scanning container specific and then most of the dependencies on tomcat utils could be removed. - We would also like to add the META-INF magic to make the resulting jars more OSGi consumable. As a project, Jetty has no desire to fork jasper. Rather we just want to re-bundle it in a way that can be consumed by the jetty project at eclipse and to use our own sanning/discovery/configuration mechanisms. We wish to be bug for bug compatible and if we did find/fix a bug, our preference would be to contribute back to apache. Also happy to contribute back changes to improve start time (eg by avoiding duplicate jar scans). We totally understand that making jasper consumable by jetty will not be a high priority for the tomcat project and that even minor changes to jar packaging can be disruptive. However, if it is desirable for other reasons, then we'd certainly be keen to lend a hand and I think most(all?) of our committers are already apache committers on some project or other. Anyway, we'll hold off making any indelible maven artefacts from our github project for a while, so that if something does happen within apache we can erase what we have done already. If there is interest here, then we could prepare a git pull request of our changes (against the apache github clone), or would we need to remember our svn and submit a diff against that? cheers -- Greg Wilkins
Tagging mod_jk 1.2.38
Hi, I plan to tag mod_jk 1.2.38 tomorrow and start release process Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1571158 - /tomcat/jk/trunk/xdocs/reference/workers.xml
Author: mturk Date: Mon Feb 24 07:24:44 2014 New Revision: 1571158 URL: http://svn.apache.org/r1571158 Log: Explain new prefer_ipv6 directive Modified: tomcat/jk/trunk/xdocs/reference/workers.xml Modified: tomcat/jk/trunk/xdocs/reference/workers.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/reference/workers.xml?rev=1571158&r1=1571157&r2=1571158&view=diff == --- tomcat/jk/trunk/xdocs/reference/workers.xml (original) +++ tomcat/jk/trunk/xdocs/reference/workers.xml Mon Feb 24 07:24:44 2014 @@ -1101,6 +1101,17 @@ This feature has been added in jk 1.2 + +When compiled with IPV6 support, this directive forces IPV6 address +resolution for host names which have both IPV6 and IPV4 addresses. In case there is +no IPV6 address defined for the given hostname this directive in ineffective. This directive will +be also ineffective if there is only IPV6 address defined or if IP address is used for "host", +either in IPV4 or IPV6 notation. + +This feature has been added in jk 1.2.38. + + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
