record security manager
Hallo, as i tested setup debian + tomcat7 following the documentation, i was refered to http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html for enabling the security manager, as it seems in debian stable (with tomcat + examples + admin debian packages installed): - enabling the security manager: tomcat does not start -- the logs are not clear to me This is not a tomcat problem, but debian it seems to me. So i looked further, and came across http://www.jchains.org/ but it is quiet old (2009); if correct: - it basically runs the application without security manager and records the permissions needed. - then u use that recording as a policy for your security manager - now run the application with security manager. So my question is: are there recent alternatives to this, or other good practices? mvg, Wim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2013- Remote Code Execution Severity: Important Vendor: The Apache Software Foundation Versions Affected: - - Apache Tomcat 7.0.0 to 7.0.39 Description: In very limited circumstances, it was possible for an attacker to upload a malicious JSP to a Tomcat server and then trigger the execution of that JSP. While Remote Code Execution would normally be viewed as a critical vulnerability, the circumstances under which this is possible are, in the view of the Tomcat security team, sufficiently limited that this vulnerability is viewed as important. For this attack to succeed all of the following requirements must be met: a) Using Oracle Java 1.7.0 update 25 or earlier (or any other Java implementation where java.io.File is vulnerable to null byte injection). b) A web application must be deployed to a vulnerable version of Tomcat (see previous section). c) The web application must use the Servlet 3.0 File Upload feature. d) A file location within a deployed web application must be writeable by the user the Tomcat process is running as. The Tomcat security documentation recommends against this. e) A custom listener for JMX connections (e.g. the JmxRemoteListener that is not enabled by default) must be configured and be able to load classes from Tomcat's common class loader (i.e. the custom JMX listener must be placed in Tomcat's lib directory) f) The custom JMX listener must be bound to an address other than localhost for a remote attack (it is bound to localhost by default). If the custom JMX listener is bound to localhost, a local attack will still be possible. Note that requirements b) and c) may be replaced with the following requirement: g) A web application is deployed that uses Apache Commons File Upload 1.2.1 or earlier. In this case a similar vulnerability may exist on any Servlet container, not just Apache Tomcat. Mitigation: This vulnerability may be mitigated by using any one of the following mitigations: - - Upgrade to Oracle Java 1.7.0 update 40 or later (or any other Java implementation where java.io.File is not vulnerable to null byte injection). - - Use OS file permissions to prevent the process Tomcat is running as from writing to any location within a deployed application. - - Disable any custom JMX listeners - - Upgrade to Apache Tomcat 7.0.40 or later Credit: This issue was identified by Pierre Ernst of the VMware Security Engineering, Communications Response group (vSECR) and reported to the Tomcat security team via the Pivotal security team. References: [1] http://tomcat.apache.org/security-7.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUEFl4AAoJEBDAHFovYFnnR3cQAL034ZrbUeBcJ4zotNp5+ea2 llNatC3MUlg/vZ2qG8Qo4xxbdS4F53cpu90fFhKm+dFzIiRhZeHROYDv6Lu1biSu Nvq0YXV6KVJ9Js4G6HFilhy3vownvn/hMAjzmPojSYjWO5slXNfFvAlwyRrGt0Cp t5rUh4QNavhgO4m0HXJJLg+PNlSKsnGdra+0gWmq8YKtKotgu24SbPq/p3HP7TuJ nnMjx4A6r2LcoghL/nFAPp2ZwgBCtm67osObJ1uMxYhZ2I/3MztFYpSKvfVONuUK rL265wmrKLvvDdozd/Aw2d2poXdSO/oWeuhKbbzYOxpUT6iRzf+BkPUR99e6Rqso lOfLoAYuzYfK4rW/ooxVNKnHMhs+0BVfNZoclKCDSvz+a9dIVS5XD6KcyJQ3uv12 ujyTGaGhLuS/ciAVS372Dx8H0/mfd5nZCkYL6NDyzSWSmb5eG4XxqrLi77yByvAT ulSAyg1UWk8sRgQ4AY3belH3jDiN1rHSWJAaB+WVwszQdCe4iXgDyB1u4ES22oAN Ymrg5l7tLQ8/9LyMvlQ0tE4f+OYE6kki6e4JMc2cMqPL/rcjiUnLWZ7YUyx92RM1 LRt9QhMd1h3Uwle7a7LxqJCGf/rIPwRmrjTYYWt43np1Adx7y2RuZOTDjEY98sN3 oCLjuSCalVcBX9hGaJ7n =98BB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: record security manager
Wim Bertels wrote: Hallo, as i tested setup debian + tomcat7 there are many versions of Tomcat 7.x. Which version precisely ? (There is a version.sh script somewhere, which will tell you) following the documentation, i was refered to http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html for enabling the security manager, As I recall, under Debian, there is a setting in /etc/default/tomcatx, like SECURITY=YES/NO which takes care of that for you. as it seems in debian stable (with tomcat + examples + admin debian packages installed): - enabling the security manager: tomcat does not start -- the logs are not clear to me But maybe they would be clear to someone here. What do they say ? This is not a tomcat problem, but debian it seems to me. Also note, if it is not clear : the security manager is not a specific Tomcat thing, it is a Java JVM thing. It is the JVM which runs Tomcat which enforces some security restrictions upon Java programs which run under it. That includes Tomcat java code, and the java code of the applications which run under Tomcat. So i looked further, and came across http://www.jchains.org/ but it is quiet old (2009); if correct: - it basically runs the application without security manager and records the permissions needed. - then u use that recording as a policy for your security manager - now run the application with security manager. So my question is: are there recent alternatives to this, or other good practices? mvg, Wim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, September 10, 2014 9:00 AM To: Tomcat Users List Cc: Tomcat Developers List; annou...@apache.org; annou...@tomcat.apache.org; fulldisclos...@seclists.org; bugt...@securityfocus.com Subject: [SECURITY] CVE-2013- Remote Code Execution in Apache Tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2013- Remote Code Execution Severity: Important Vendor: The Apache Software Foundation Versions Affected: - - Apache Tomcat 7.0.0 to 7.0.39 Description: In very limited circumstances, it was possible for an attacker to upload a malicious JSP to a Tomcat server and then trigger the execution of that JSP. While Remote Code Execution would normally be viewed as a critical vulnerability, the circumstances under which this is possible are, in the view of the Tomcat security team, sufficiently limited that this vulnerability is viewed as important. For this attack to succeed all of the following requirements must be met: a) Using Oracle Java 1.7.0 update 25 or earlier (or any other Java implementation where java.io.File is vulnerable to null byte injection). b) A web application must be deployed to a vulnerable version of Tomcat (see previous section). c) The web application must use the Servlet 3.0 File Upload feature. d) A file location within a deployed web application must be writeable by the user the Tomcat process is running as. The Tomcat security documentation recommends against this. How does one avoid this if deploying war files? By definition, doesn't the exploded directory need to be writable by the Tomcat process? The only way I can think of is to not explode the war file, but that is a performance hit. e) A custom listener for JMX connections (e.g. the JmxRemoteListener that is not enabled by default) must be configured and be able to load classes from Tomcat's common class loader (i.e. the custom JMX listener must be placed in Tomcat's lib directory) f) The custom JMX listener must be bound to an address other than localhost for a remote attack (it is bound to localhost by default). If the custom JMX listener is bound to localhost, a local attack will still be possible. Are these two an AND case? If using the JmxRemoteListener, wouldn't one normally deploy it in Tomcat/lib? Finally, if you've taken care of a) b), is this sufficient to mitigate the problem, even if any/all of c) thru g) apply? Note that requirements b) and c) may be replaced with the following requirement: g) A web application is deployed that uses Apache Commons File Upload 1.2.1 or earlier. In this case a similar vulnerability may exist on any Servlet container, not just Apache Tomcat. Mitigation: This vulnerability may be mitigated by using any one of the following mitigations: - - Upgrade to Oracle Java 1.7.0 update 40 or later (or any other Java implementation where java.io.File is not vulnerable to null byte injection). - - Use OS file permissions to prevent the process Tomcat is running as from writing to any location within a deployed application. - - Disable any custom JMX listeners - - Upgrade to Apache Tomcat 7.0.40 or later Credit: This issue was identified by Pierre Ernst of the VMware Security Engineering, Communications Response group (vSECR) and reported to the Tomcat security team via the Pivotal security team. References: [1] http://tomcat.apache.org/security-7.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUEFl4AAoJEBDAHFovYFnnR3cQAL034ZrbUeBcJ4zotNp5+ea 2 llNatC3MUlg/vZ2qG8Qo4xxbdS4F53cpu90fFhKm+dFzIiRhZeHROYDv6Lu1biSu Nvq0YXV6KVJ9Js4G6HFilhy3vownvn/hMAjzmPojSYjWO5slXNfFvAlwyRrGt0C p t5rUh4QNavhgO4m0HXJJLg+PNlSKsnGdra+0gWmq8YKtKotgu24SbPq/p3HP7T uJ nnMjx4A6r2LcoghL/nFAPp2ZwgBCtm67osObJ1uMxYhZ2I/3MztFYpSKvfVONu UK rL265wmrKLvvDdozd/Aw2d2poXdSO/oWeuhKbbzYOxpUT6iRzf+BkPUR99e6R qso lOfLoAYuzYfK4rW/ooxVNKnHMhs+0BVfNZoclKCDSvz+a9dIVS5XD6KcyJQ3uv1 2 ujyTGaGhLuS/ciAVS372Dx8H0/mfd5nZCkYL6NDyzSWSmb5eG4XxqrLi77yByvA T ulSAyg1UWk8sRgQ4AY3belH3jDiN1rHSWJAaB+WVwszQdCe4iXgDyB1u4ES22 oAN Ymrg5l7tLQ8/9LyMvlQ0tE4f+OYE6kki6e4JMc2cMqPL/rcjiUnLWZ7YUyx92RM1 LRt9QhMd1h3Uwle7a7LxqJCGf/rIPwRmrjTYYWt43np1Adx7y2RuZOTDjEY98sN 3 oCLjuSCalVcBX9hGaJ7n =98BB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat
On 9/10/2014 11:10 AM, Jeffrey Janner wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, September 10, 2014 9:00 AM To: Tomcat Users List Cc: Tomcat Developers List; annou...@apache.org; annou...@tomcat.apache.org; fulldisclos...@seclists.org; bugt...@securityfocus.com Subject: [SECURITY] CVE-2013- Remote Code Execution in Apache Tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2013- Remote Code Execution Severity: Important Vendor: The Apache Software Foundation Versions Affected: - - Apache Tomcat 7.0.0 to 7.0.39 Description: In very limited circumstances, it was possible for an attacker to upload a malicious JSP to a Tomcat server and then trigger the execution of that JSP. While Remote Code Execution would normally be viewed as a critical vulnerability, the circumstances under which this is possible are, in the view of the Tomcat security team, sufficiently limited that this vulnerability is viewed as important. For this attack to succeed all of the following requirements must be met: a) Using Oracle Java 1.7.0 update 25 or earlier (or any other Java implementation where java.io.File is vulnerable to null byte injection). b) A web application must be deployed to a vulnerable version of Tomcat (see previous section). c) The web application must use the Servlet 3.0 File Upload feature. d) A file location within a deployed web application must be writeable by the user the Tomcat process is running as. The Tomcat security documentation recommends against this. How does one avoid this if deploying war files? By definition, doesn't the exploded directory need to be writable by the Tomcat process? The only way I can think of is to not explode the war file, but that is a performance hit. e) A custom listener for JMX connections (e.g. the JmxRemoteListener that is not enabled by default) must be configured and be able to load classes from Tomcat's common class loader (i.e. the custom JMX listener must be placed in Tomcat's lib directory) f) The custom JMX listener must be bound to an address other than localhost for a remote attack (it is bound to localhost by default). If the custom JMX listener is bound to localhost, a local attack will still be possible. Are these two an AND case? That's what he said: For this attack to succeed all of the following requirements must be met: If using the JmxRemoteListener, wouldn't one normally deploy it in Tomcat/lib? Finally, if you've taken care of a) b), is this sufficient to mitigate the problem, even if any/all of c) thru g) apply? Note that requirements b) and c) may be replaced with the following requirement: g) A web application is deployed that uses Apache Commons File Upload 1.2.1 or earlier. In this case a similar vulnerability may exist on any Servlet container, not just Apache Tomcat. Mitigation: This vulnerability may be mitigated by using any one of the following mitigations: - - Upgrade to Oracle Java 1.7.0 update 40 or later (or any other Java implementation where java.io.File is not vulnerable to null byte injection). - - Use OS file permissions to prevent the process Tomcat is running as from writing to any location within a deployed application. - - Disable any custom JMX listeners - - Upgrade to Apache Tomcat 7.0.40 or later Credit: This issue was identified by Pierre Ernst of the VMware Security Engineering, Communications Response group (vSECR) and reported to the Tomcat security team via the Pivotal security team. References: [1] http://tomcat.apache.org/security-7.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUEFl4AAoJEBDAHFovYFnnR3cQAL034ZrbUeBcJ4zotNp5+ea 2 llNatC3MUlg/vZ2qG8Qo4xxbdS4F53cpu90fFhKm+dFzIiRhZeHROYDv6Lu1biSu Nvq0YXV6KVJ9Js4G6HFilhy3vownvn/hMAjzmPojSYjWO5slXNfFvAlwyRrGt0C p t5rUh4QNavhgO4m0HXJJLg+PNlSKsnGdra+0gWmq8YKtKotgu24SbPq/p3HP7T uJ nnMjx4A6r2LcoghL/nFAPp2ZwgBCtm67osObJ1uMxYhZ2I/3MztFYpSKvfVONu UK rL265wmrKLvvDdozd/Aw2d2poXdSO/oWeuhKbbzYOxpUT6iRzf+BkPUR99e6R qso lOfLoAYuzYfK4rW/ooxVNKnHMhs+0BVfNZoclKCDSvz+a9dIVS5XD6KcyJQ3uv1 2 ujyTGaGhLuS/ciAVS372Dx8H0/mfd5nZCkYL6NDyzSWSmb5eG4XxqrLi77yByvA T ulSAyg1UWk8sRgQ4AY3belH3jDiN1rHSWJAaB+WVwszQdCe4iXgDyB1u4ES22 oAN Ymrg5l7tLQ8/9LyMvlQ0tE4f+OYE6kki6e4JMc2cMqPL/rcjiUnLWZ7YUyx92RM1 LRt9QhMd1h3Uwle7a7LxqJCGf/rIPwRmrjTYYWt43np1Adx7y2RuZOTDjEY98sN 3 oCLjuSCalVcBX9hGaJ7n =98BB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -
Context parameter override?
Hello We have a setup which compiles WAR applications once and deploys them in various environments. Each environment has its own per application Log4j configuration (WARN for production, DEBUG for development etc.) which should survive application redeployment. So far the solution is: webapps/myapp/WEB-INF/web.xml ... context-param param-namelog4jConfigLocation/param-name param-valuefile:///opt/tomcat6/conf/myapp/log4j.xml/param-value /context-param ... Pretty standard, works. Question is, how can I make sure the Log4j configuration path is not hard coded in the 'web.xml' at development time. Idea was: webapps/myapp/META-INF/context.xml ... Parameter name=log4jConfigLocation value=file://TBD / ... and change it after the application deployment: conf/Catalina/localhost/myapp.xml ... Parameter name=log4jConfigLocation value=file:///opt/tomcat6/conf/myapp/log4j.xml / ... Tomcat simply ignores both of these context XML files, or at least the parameters defined in them. I read through all mailing lists, all documentations, switched on debug to the 'finest' level, still no avail. How difficult can this be? Details: Server version: Apache Tomcat/6.0.35 Server built: Nov 28 2011 11:20:06 Server number: 6.0.35.0 OS Name:Linux OS Version: 2.6.18-348.el5 Architecture: amd64 JVM Version:1.6.0_30-b12 JVM Vendor: Sun Microsystems Inc. Cheers B.
Re: Context parameter override?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2014 8:40 AM, sbre...@hotmail.com wrote: Hello We have a setup which compiles WAR applications once and deploys them in various environments. Each environment has its own per application Log4j configuration (WARN for production, DEBUG for development etc.) which should survive application redeployment. So far the solution is: webapps/myapp/WEB-INF/web.xml ... context-param param-namelog4jConfigLocation/param-name param-valuefile:///opt/tomcat6/conf/myapp/log4j.xml/param-value /context-param ... Pretty standard, works. Question is, how can I make sure the Log4j configuration path is not hard coded in the 'web.xml' at development time. Idea was: webapps/myapp/META-INF/context.xml ... Parameter name=log4jConfigLocation value=file://TBD / ... and change it after the application deployment: conf/Catalina/localhost/myapp.xml ... Parameter name=log4jConfigLocation value=file:///opt/tomcat6/conf/myapp/log4j.xml / ... Tomcat simply ignores both of these context XML files, or at least the parameters defined in them. I read through all mailing lists, all documentations, switched on debug to the 'finest' level, still no avail. How difficult can this be? Details: Server version: Apache Tomcat/6.0.35 Server built: Nov 28 2011 11:20:06 Server number: 6.0.35.0 OS Name:Linux OS Version: 2.6.18-348.el5 Architecture: amd64 JVM Version: 1.6.0_30-b12 JVM Vendor: Sun Microsystems Inc. Cheers B. I'm just noodling - haven't tried this. Your mileage may vary, void where prohibited, etc., etc., etc. How about: 1. use Parameter in context.xml to set the logging level: Parameter name=LoggingLevel value=DEBUG override=false/ 2. Write a servlet context listener to read the parameter 3. Set the logging level accordingly Place the servlet context listener as the first one in your web.xml so the new logging level is set before any other logging occurs. This way your log4j.xml doesn't have to change, and you can just use an appropriate $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml to set the desired logging level. This seems as if it should work. . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUEHZvAAoJEEFGbsYNeTwte+YH/12yWANWhJ2+6MwCKHkdWh5G AQi20L9LVdjTtWYx+vpZvktqiDSNvYAUTTx2+AJaolo9puqsaSLf5kfR1hTgbGy8 sMrBPLbJY1qY4uZruK5ISPc1I3nbo2j/uDtSpClbfMSGKLUIqcISiCxYwwcb/u5f UUGXSorSddwCEE2i5Sk8wHpYMcEjRDXa99t6qR5I4Xe6Tb9KG8rJ9yfiB1//snwO bOGmroKgYRB1sz7cM2xffZNW+3GzN/Z8py0GqdR07+sEDMTYpvVcW0Iu1ebmUtU6 Aw2QTcK9pu4kU+Q2DA7vOycXTdG/8XgFOnQCvhXWRvy63iR1pXiz6KNCZ6qBkrk= =nU9F -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context parameter override?
Mark Eggers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2014 8:40 AM, sbre...@hotmail.com wrote: Hello We have a setup which compiles WAR applications once and deploys them in various environments. Each environment has its own per application Log4j configuration (WARN for production, DEBUG for development etc.) which should survive application redeployment. So far the solution is: webapps/myapp/WEB-INF/web.xml ... context-param param-namelog4jConfigLocation/param-name param-valuefile:///opt/tomcat6/conf/myapp/log4j.xml/param-value /context-param ... Pretty standard, works. Question is, how can I make sure the Log4j configuration path is not hard coded in the 'web.xml' at development time. Idea was: webapps/myapp/META-INF/context.xml ... Parameter name=log4jConfigLocation value=file://TBD / ... and change it after the application deployment: conf/Catalina/localhost/myapp.xml ... Parameter name=log4jConfigLocation value=file:///opt/tomcat6/conf/myapp/log4j.xml / ... Tomcat simply ignores both of these context XML files, or at least the parameters defined in them. I read through all mailing lists, all documentations, switched on debug to the 'finest' level, still no avail. How difficult can this be? Details: Server version: Apache Tomcat/6.0.35 Server built: Nov 28 2011 11:20:06 Server number: 6.0.35.0 OS Name:Linux OS Version: 2.6.18-348.el5 Architecture: amd64 JVM Version: 1.6.0_30-b12 JVM Vendor: Sun Microsystems Inc. Cheers B. I'm just noodling - haven't tried this. Your mileage may vary, void where prohibited, etc., etc., etc. How about: 1. use Parameter in context.xml to set the logging level: Parameter name=LoggingLevel value=DEBUG override=false/ 2. Write a servlet context listener to read the parameter 3. Set the logging level accordingly Place the servlet context listener as the first one in your web.xml so the new logging level is set before any other logging occurs. This way your log4j.xml doesn't have to change, and you can just use an appropriate $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml to set the desired logging level. This seems as if it should work. . . . just my two cents /mde/ Mark, I was watching this thread, because I think that the original question has a wider scope, which has been touched a few times in the past, but to which I have never seen a really convincing answer. Example : I have customers who are security-conscious, and I do not have access to their servers. When I need to send them an application update, it must be in the form of a WAR, which the local sysadmins then deploy on the server. But in that application, there is a third-party authentication servlet filter, which requires 3 parameters in web.xml : - the FQDN of an authentication server - a login on that authentication server - a password for that login This is specific to each customer. (Of course, there are plenty more parameters in web.xml which are not customer-specific, but may change with a new version of the app). So I cannot make a single WAR, and just send it to all. I have (for now) to create a separate WAR for each customer. And I have to know their password, which they do not like. Otherwise, my customer sysadmins would have to unpack the WAR, edit web.xml to insert their specific values, and re-pack the WAR. Which they do not like to do either. My customers also do not like a solution consisting in having these parameters defined somehow as JVM properties that must be given on the java command-line, because then any user with a console on the server can see them by doing a simple ps -ef. So, yes, there are a lot of things which they don't like. But such it is, and I am only a small supplier happy to have them as customer, and I do not want to pick a fight with the sysadmins. Because that's like picking a fight with a waiter in a restaurant (*). So is there an easy generic way to solve this, without having to write some specific code to do it ? (which I think would also solve the OP's problem) (*) I once heard one say to a colleague : Did you see ? he ate it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context parameter override?
Thanks, I am afraid I read a similar solution earlier which I did not favour for multiple reasons: - it is a run-time configuration question (handled by DevOps, Ops) to have various logging levels for various deployed applications on the same Tomcat - we would like to have full control of logging (which class at what level etc.) during run-time, i.e. be able to have per web application Log4j configuration file - writing servlet is beyond the scope of our responsibility (DevOps, Ops) - keep the Dev and Ops responsibilities separated What puzzles me is the Context / Parameter feature of Tomcat. (context-param from Java is clear.) There are at least 3 locations to define Tomcat level parameters: - server.xml / Host - webapps / ... / context.xml - conf/.../myapp.xml None of these I managed to configure. Is there any working example from Tomcat? Shall I recommend Dev to hard code a path to the Log4j configuration in web.xml, i.e. /usr/local/etc/myapp_log4j.xml, which is potentially a symbolic link to an actual file that can stay anywhere on the file system? Date: Wed, 10 Sep 2014 09:03:59 -0700 From: its_toas...@yahoo.com.INVALID To: users@tomcat.apache.org Subject: Re: Context parameter override? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2014 8:40 AM, sbre...@hotmail.com wrote: Hello We have a setup which compiles WAR applications once and deploys them in various environments. Each environment has its own per application Log4j configuration (WARN for production, DEBUG for development etc.) which should survive application redeployment. So far the solution is: webapps/myapp/WEB-INF/web.xml ... context-param param-namelog4jConfigLocation/param-name param-valuefile:///opt/tomcat6/conf/myapp/log4j.xml/param-value /context-param ... Pretty standard, works. Question is, how can I make sure the Log4j configuration path is not hard coded in the 'web.xml' at development time. Idea was: webapps/myapp/META-INF/context.xml ... Parameter name=log4jConfigLocation value=file://TBD / ... and change it after the application deployment: conf/Catalina/localhost/myapp.xml ... Parameter name=log4jConfigLocation value=file:///opt/tomcat6/conf/myapp/log4j.xml / ... Tomcat simply ignores both of these context XML files, or at least the parameters defined in them. I read through all mailing lists, all documentations, switched on debug to the 'finest' level, still no avail. How difficult can this be? Details: Server version: Apache Tomcat/6.0.35 Server built: Nov 28 2011 11:20:06 Server number: 6.0.35.0 OS Name:Linux OS Version: 2.6.18-348.el5 Architecture: amd64 JVM Version: 1.6.0_30-b12 JVM Vendor: Sun Microsystems Inc. Cheers B. I'm just noodling - haven't tried this. Your mileage may vary, void where prohibited, etc., etc., etc. How about: 1. use Parameter in context.xml to set the logging level: Parameter name=LoggingLevel value=DEBUG override=false/ 2. Write a servlet context listener to read the parameter 3. Set the logging level accordingly Place the servlet context listener as the first one in your web.xml so the new logging level is set before any other logging occurs. This way your log4j.xml doesn't have to change, and you can just use an appropriate $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml to set the desired logging level. This seems as if it should work. . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUEHZvAAoJEEFGbsYNeTwte+YH/12yWANWhJ2+6MwCKHkdWh5G AQi20L9LVdjTtWYx+vpZvktqiDSNvYAUTTx2+AJaolo9puqsaSLf5kfR1hTgbGy8 sMrBPLbJY1qY4uZruK5ISPc1I3nbo2j/uDtSpClbfMSGKLUIqcISiCxYwwcb/u5f UUGXSorSddwCEE2i5Sk8wHpYMcEjRDXa99t6qR5I4Xe6Tb9KG8rJ9yfiB1//snwO bOGmroKgYRB1sz7cM2xffZNW+3GzN/Z8py0GqdR07+sEDMTYpvVcW0Iu1ebmUtU6 Aw2QTcK9pu4kU+Q2DA7vOycXTdG/8XgFOnQCvhXWRvy63iR1pXiz6KNCZ6qBkrk= =nU9F -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat
On 10/09/2014 16:10, Jeffrey Janner wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, September 10, 2014 9:00 AM To: Tomcat Users List Cc: Tomcat Developers List; annou...@apache.org; annou...@tomcat.apache.org; fulldisclos...@seclists.org; bugt...@securityfocus.com Subject: [SECURITY] CVE-2013- Remote Code Execution in Apache Tomcat CVE-2013- Remote Code Execution Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 7.0.0 to 7.0.39 Description: In very limited circumstances, it was possible for an attacker to upload a malicious JSP to a Tomcat server and then trigger the execution of that JSP. While Remote Code Execution would normally be viewed as a critical vulnerability, the circumstances under which this is possible are, in the view of the Tomcat security team, sufficiently limited that this vulnerability is viewed as important. For this attack to succeed all of the following requirements must be met: a) Using Oracle Java 1.7.0 update 25 or earlier (or any other Java implementation where java.io.File is vulnerable to null byte injection). b) A web application must be deployed to a vulnerable version of Tomcat (see previous section). c) The web application must use the Servlet 3.0 File Upload feature. d) A file location within a deployed web application must be writeable by the user the Tomcat process is running as. The Tomcat security documentation recommends against this. How does one avoid this if deploying war files? By definition, doesn't the exploded directory need to be writable by the Tomcat process? The only way I can think of is to not explode the war file, but that is a performance hit. Don't deploy WAR files, deploy an exploded directory. You create the exploded web app with the appropriate permissions (root rw, tomcat r) and then move it into place (and move the old one out of the way at the same time). The general recommendation (see the security guide) is that the Tomcat process should not have write access apart from temp and work. e) A custom listener for JMX connections (e.g. the JmxRemoteListener that is not enabled by default) must be configured and be able to load classes from Tomcat's common class loader (i.e. the custom JMX listener must be placed in Tomcat's lib directory) f) The custom JMX listener must be bound to an address other than localhost for a remote attack (it is bound to localhost by default). If the custom JMX listener is bound to localhost, a local attack will still be possible. Are these two an AND case? All 6 are an AND case. i.e. if you don't meet any one of the requirements you are safe (this is the main reason this is rated as important rather than critical). If using the JmxRemoteListener, wouldn't one normally deploy it in Tomcat/lib? Yes, you would although in theory you might be able to install it elsewhere on the class path - I haven't tried. Finally, if you've taken care of a) b), is this sufficient to mitigate the problem, even if any/all of c) thru g) apply? Again, you have to meet all of a) through f) or all of a) plus d) through g) to be vulnerable. Mark Note that requirements b) and c) may be replaced with the following requirement: g) A web application is deployed that uses Apache Commons File Upload 1.2.1 or earlier. In this case a similar vulnerability may exist on any Servlet container, not just Apache Tomcat. Mitigation: This vulnerability may be mitigated by using any one of the following mitigations: - Upgrade to Oracle Java 1.7.0 update 40 or later (or any other Java implementation where java.io.File is not vulnerable to null byte injection). - Use OS file permissions to prevent the process Tomcat is running as from writing to any location within a deployed application. - Disable any custom JMX listeners - Upgrade to Apache Tomcat 7.0.40 or later Credit: This issue was identified by Pierre Ernst of the VMware Security Engineering, Communications Response group (vSECR) and reported to the Tomcat security team via the Pivotal security team. References: [1] http://tomcat.apache.org/security-7.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context parameter override?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2014 9:43 AM, André Warnier wrote: Mark Eggers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2014 8:40 AM, sbre...@hotmail.com wrote: Hello We have a setup which compiles WAR applications once and deploys them in various environments. Each environment has its own per application Log4j configuration (WARN for production, DEBUG for development etc.) which should survive application redeployment. So far the solution is: webapps/myapp/WEB-INF/web.xml ... context-param param-namelog4jConfigLocation/param-name param-valuefile:///opt/tomcat6/conf/myapp/log4j.xml/param-value /context-param ... Pretty standard, works. Question is, how can I make sure the Log4j configuration path is not hard coded in the 'web.xml' at development time. Idea was: webapps/myapp/META-INF/context.xml ... Parameter name=log4jConfigLocation value=file://TBD / ... and change it after the application deployment: conf/Catalina/localhost/myapp.xml ... Parameter name=log4jConfigLocation value=file:///opt/tomcat6/conf/myapp/log4j.xml / ... Tomcat simply ignores both of these context XML files, or at least the parameters defined in them. I read through all mailing lists, all documentations, switched on debug to the 'finest' level, still no avail. How difficult can this be? Details: Server version: Apache Tomcat/6.0.35 Server built: Nov 28 2011 11:20:06 Server number: 6.0.35.0 OS Name:Linux OS Version: 2.6.18-348.el5 Architecture: amd64 JVM Version: 1.6.0_30-b12 JVM Vendor: Sun Microsystems Inc. Cheers B. I'm just noodling - haven't tried this. Your mileage may vary, void where prohibited, etc., etc., etc. How about: 1. use Parameter in context.xml to set the logging level: Parameter name=LoggingLevel value=DEBUG override=false/ 2. Write a servlet context listener to read the parameter 3. Set the logging level accordingly Place the servlet context listener as the first one in your web.xml so the new logging level is set before any other logging occurs. This way your log4j.xml doesn't have to change, and you can just use an appropriate $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml to set the desired logging level. This seems as if it should work. . . . just my two cents /mde/ Mark, I was watching this thread, because I think that the original question has a wider scope, which has been touched a few times in the past, but to which I have never seen a really convincing answer. Example : I have customers who are security-conscious, and I do not have access to their servers. When I need to send them an application update, it must be in the form of a WAR, which the local sysadmins then deploy on the server. But in that application, there is a third-party authentication servlet filter, which requires 3 parameters in web.xml : - the FQDN of an authentication server - a login on that authentication server - a password for that login This is specific to each customer. (Of course, there are plenty more parameters in web.xml which are not customer-specific, but may change with a new version of the app). So I cannot make a single WAR, and just send it to all. I have (for now) to create a separate WAR for each customer. And I have to know their password, which they do not like. Otherwise, my customer sysadmins would have to unpack the WAR, edit web.xml to insert their specific values, and re-pack the WAR. Which they do not like to do either. My customers also do not like a solution consisting in having these parameters defined somehow as JVM properties that must be given on the java command-line, because then any user with a console on the server can see them by doing a simple ps -ef. So, yes, there are a lot of things which they don't like. But such it is, and I am only a small supplier happy to have them as customer, and I do not want to pick a fight with the sysadmins. Because that's like picking a fight with a waiter in a restaurant (*). So is there an easy generic way to solve this, without having to write some specific code to do it ? (which I think would also solve the OP's problem) (*) I once heard one say to a colleague : Did you see ? he ate it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org André, I am not aware of any generic Tomcat mechanism to do this without some code. The quick and dirty method that I described in the previous message is Tomcat-specific (which is OK since this is the Tomcat mailing list). I can think of a few ways to do this, but all would require some code. A. Parameters in appname.xml (ie., application-specific context.xml) You can do this and read the parameters from a listener and configure a singleton. Then
Re: Context parameter override?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2014 11:55 AM, Mark Eggers wrote: Context ctx = new InitialContext(); Integer maxExemptions = ctx.lookup(java:comp/env/maxExemptions); Try / catch and other issues are left as exercises for the reader. Urp, at least get the casting correct :-( Context ctx = new InitialContext(); Integer mE = (Integer)ctx.lookup(java:comp/env/maxExemptions); . . . and this is why I'm an architect and not a developer /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUEJ+bAAoJEEFGbsYNeTwt6OsH/RVET2KW8wsXnWeyEc1r/Wuf 0fnbWnLaiFnE3X+pgh+zO48XbUSbRnrlX0BzoTFPNirpTL6O+Q/vgn5Z9kk/xq/E 72uFiHo7nZhAr7acOATskd5IkA/vmVk/tf6JyCG3AMLI7wRIOiqgJlwwoBzK8fqk IraQ59S96tyYGM56gJd17WA3vF1had+xy2+TclyyJDusU4eSMPqpFDmFvM5Iy5+/ q3QsCwVpO33og27SC+CHZh4CLoTjiLiyYzzzf3P9LkIwb30dEzqjEgv0JGBPaKjp 0Wm4qj+jxOt17Degir238Qom+liJS0L8e2tHrC0EBM+IYMNgKNEt8RvNDz7fRWs= =jaAJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context parameter override?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Comments inline. Conventions for this list are to post replies at the end or inline. It makes reading the thread easier. On 9/10/2014 10:52 AM, sbre...@hotmail.com wrote: Thanks, I am afraid I read a similar solution earlier which I did not favour for multiple reasons: - it is a run-time configuration question (handled by DevOps, Ops) to have various logging levels for various deployed applications on the same Tomcat This is quite possible for the solution I proposed. Each application has its own [appname].xml, so the logging can be changed per application. - we would like to have full control of logging (which class at what level etc.) during run-time, i.e. be able to have per web application Log4j configuration file Ah, during run-time. I didn't see that requirement in your original message. That's an entirely different kettle of fish. The Parameter element of the Context is a Tomcat-specific way to specify context initialization parameters. As implied by the name context initialization, they're read once at context start-up and made available to the context. Changing them through the life cycle of that context is not possible. You would have to edit the appname.xml and restart the context. See my JMX comments to André concerning how to do this on a running application. I've hacked together a listener that exposes all of the log4j information as JMX (based on the following blog post: http://www.jroller.com/ray/entry/managing_log4j_logging_levels_for). I then was able to modify the various loggers during run time using JConsole. Obviously you'll need some sensible initial values. - writing servlet is beyond the scope of our responsibility (DevOps, Ops) I agree. You will need the developers to get involved in order to provide the mechanism for you. I don't know of any configuration-only mechanism to accomplish this . . . Hmm . . . hang on a second. If log4j is configured using configureAndWatch (available via DOMConfigurator and PropertyConfigurator), then a thread is spawned to watch the configuration file for changes. Since this method starts a watchdog thread and there's no way to stop it in log4j 1.2.x (according to the log4j FAQ), this should not be used in a J2EE environment where the applications are recycled. - keep the Dev and Ops responsibilities separated Agreed. This is why I think Dev needs to give Ops the handles to tweak the logging levels (most likely via JMX). What puzzles me is the Context / Parameter feature of Tomcat. (context-param from Java is clear.) There are at least 3 locations to define Tomcat level parameters: - server.xml / Host - webapps / ... / context.xml - conf/.../myapp.xml None of these I managed to configure. Is there any working example from Tomcat? They all work. Doing this at in server.xml means that you'll have to restart the server when the values change. Doing this in context.xml (appname.xml) means that you'll have to restart the application when the values change. Shall I recommend Dev to hard code a path to the Log4j configuration in web.xml, i.e. /usr/local/etc/myapp_log4j.xml, which is potentially a symbolic link to an actual file that can stay anywhere on the file system? No. See above concerning the safety and applicability of using configureAndWatch in a J2EE environment. Changing log4j.xml on the fly will create thread leaks. Who knows what the environment will be like once you reload multiple applications using configureAndWatch. . . . just my two cents /mde/ Date: Wed, 10 Sep 2014 09:03:59 -0700 From: its_toas...@yahoo.com.INVALID To: users@tomcat.apache.org Subject: Re: Context parameter override? On 9/10/2014 8:40 AM, sbre...@hotmail.com wrote: Hello We have a setup which compiles WAR applications once and deploys them in various environments. Each environment has its own per application Log4j configuration (WARN for production, DEBUG for development etc.) which should survive application redeployment. So far the solution is: webapps/myapp/WEB-INF/web.xml ... context-param param-namelog4jConfigLocation/param-name param-valuefile:///opt/tomcat6/conf/myapp/log4j.xml/param-value /context-param ... Pretty standard, works. Question is, how can I make sure the Log4j configuration path is not hard coded in the 'web.xml' at development time. Idea was: webapps/myapp/META-INF/context.xml ... Parameter name=log4jConfigLocation value=file://TBD / ... and change it after the application deployment: conf/Catalina/localhost/myapp.xml ... Parameter name=log4jConfigLocation value=file:///opt/tomcat6/conf/myapp/log4j.xml / ... Tomcat simply ignores both of these context XML files, or at least the parameters defined in them. I read through all mailing lists, all documentations, switched on debug to the 'finest' level, still no avail. How difficult can this be? Details: Server version: Apache
Why does mod_jk bypass Apache authorization?
Since switching from Apache 2.2 authorization gets bypassed for many JkMounts (except jk-status). If I cancel the browser password popup, I get a 401-page. It is not, as I expect, the one from Apache, but instead from JBoss, which it shouldn't have been allowed to talk to. (I found this because unauthorized users are talking to JBoss.) On the receiving end we have both JBoss 4 and Wildfly 7. This is both with Apache/2.4.3 (Unix) mod_jk/1.2.37 and Apache/2.4.10 (Unix) mod_jk/1.2.40. Configuration is always like Location /XYZ/* JkMount XYZ AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location I even have a case where the identical setup (worker definition, Location, file permission and content) works on 2.4.3 but not on 2.4.10. For other JkMounts both versions behave wrongly. If I raise the debug level, I don't see anything about how it parses this. When I call the URL, it says there is no directive protecting it. It doesn't make a difference whether AuthName is the same as the Realm in JBoss or not. 안녕히 계세요 / coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn Daniel Pfeiffer -- 배운다 / lerne / learn / apprends Esperanto: http://lernu.net / http://ikurso.net Reliability, Perl programming and much more in Makefiles: http://makepp.sourceforge.net - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
Daniel Pfeiffer wrote: Since switching from Apache 2.2 authorization gets bypassed for many JkMounts (except jk-status). If I cancel the browser password popup, I get a 401-page. It is not, as I expect, the one from Apache, but instead from JBoss, which it shouldn't have been allowed to talk to. (I found this because unauthorized users are talking to JBoss.) On the receiving end we have both JBoss 4 and Wildfly 7. This is both with Apache/2.4.3 (Unix) mod_jk/1.2.37 and Apache/2.4.10 (Unix) mod_jk/1.2.40. Configuration is always like Location /XYZ/* JkMount XYZ AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location I even have a case where the identical setup (worker definition, Location, file permission and content) works on 2.4.3 but not on 2.4.10. For other JkMounts both versions behave wrongly. If I raise the debug level, I don't see anything about how it parses this. When I call the URL, it says there is no directive protecting it. It doesn't make a difference whether AuthName is the same as the Realm in JBoss or not. Hi. I think that the problem may be the scope of the JkMount that you have above. I do not think that it is limited to your Location section. It may be global, even when it is in that section. Can you try instead : Location /XYZ/* SetHandler jakarta-servlet AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location See here for more details : https://tomcat.apache.org/connectors-doc/reference/apache.html section : Using SetHandler and Environment Variables - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2014 12:52 PM, André Warnier wrote: Daniel Pfeiffer wrote: Since switching from Apache 2.2 authorization gets bypassed for many JkMounts (except jk-status). If I cancel the browser password popup, I get a 401-page. It is not, as I expect, the one from Apache, but instead from JBoss, which it shouldn't have been allowed to talk to. (I found this because unauthorized users are talking to JBoss.) On the receiving end we have both JBoss 4 and Wildfly 7. This is both with Apache/2.4.3 (Unix) mod_jk/1.2.37 and Apache/2.4.10 (Unix) mod_jk/1.2.40. Configuration is always like Location /XYZ/* JkMount XYZ AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location I even have a case where the identical setup (worker definition, Location, file permission and content) works on 2.4.3 but not on 2.4.10. For other JkMounts both versions behave wrongly. If I raise the debug level, I don't see anything about how it parses this. When I call the URL, it says there is no directive protecting it. It doesn't make a difference whether AuthName is the same as the Realm in JBoss or not. Hi. I think that the problem may be the scope of the JkMount that you have above. I do not think that it is limited to your Location section. It may be global, even when it is in that section. Can you try instead : Location /XYZ/* SetHandler jakarta-servlet AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location See here for more details : https://tomcat.apache.org/connectors-doc/reference/apache.html section : Using SetHandler and Environment Variables I think all you might need is JkMount: Location /XYZ JkMount AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location Also, I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) If you want everything INCLUDING /XYZ protected, then the above Location directive is what you want. If you want only things UNDER /XYZ protected (but NOT /XYZ), then you need: Location /XYZ/ JkMount AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location based on the Apache 2.4.x documentation. . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUELC3AAoJEEFGbsYNeTwtfnIH+wR8DiOAV1Q/KTkl9eBcjuUW nGlg5L04HiyLqIYEYZvM2f3DoaWSnvmU5+D7Wrh1AO34ymkNFu5YzB1m67JV4OZ8 zSafBfnaofwYHFJSwCxNe3Qa3Y/h9A5dwGZzlR9O2N+EAVBLtOLqQTd66HyN8AgK KLk3g8FvGRynLpT0+TfPhWA+5UJyCoTaQyVCDy37cIMFYg35hdxPreAtCk0gLQEK Msz7SOU+J0aNNSP6FUMNb7hqzPxlPF/GzEUartazmM1n6HkxXiYIb+Xj81bCi7P2 lH+1W+do1Lxs3++ZZZOrjU28fE5s65BnVIfl1tQcyhYT/9E7cH1KmUcoaxp0iWY= =HdFz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 9/10/14 3:40 PM, Daniel Pfeiffer wrote: Since switching from Apache 2.2 authorization gets bypassed for many JkMounts (except jk-status). If I cancel the browser password popup, I get a 401-page. It is not, as I expect, the one from Apache, but instead from JBoss, which it shouldn't have been allowed to talk to. (I found this because unauthorized users are talking to JBoss.) On the receiving end we have both JBoss 4 and Wildfly 7. This is both with Apache/2.4.3 (Unix) mod_jk/1.2.37 and Apache/2.4.10 (Unix) mod_jk/1.2.40. Configuration is always like Location /XYZ/* JkMount XYZ AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location I even have a case where the identical setup (worker definition, Location, file permission and content) works on 2.4.3 but not on 2.4.10. For other JkMounts both versions behave wrongly. If I raise the debug level, I don't see anything about how it parses this. When I call the URL, it says there is no directive protecting it. It doesn't make a difference whether AuthName is the same as the Realm in JBoss or not. Do you have an ErrorDocument set for 401? What is it? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUELFFAAoJEBzwKT+lPKRY1DUP/0GgmwYhmqeQ3VNpHTl3UNkg 0FTboIyXikOsEl8+ew0m8hYJGdUloClBwHFbJhF8UkZEY8MOnLJwkAt3ZZ2vpB2d PbreF0TfM6mUzr0jFF9a2Ew+CfSgpoNR3idhSAIniJCl2qSlu2Nc/qxa/jn1SLqU 7ZDaXlT5eDZGypRI0gyswKhVz5C9yF91p0r7HJtdWibinrRuB9hBR38ggACn9kF6 J0nY8L6Qod2KNc8EAVlSdvZlLBBN9GjBvQeA+zrZYn///lutl6L1uOd6tfp5ouqd z5Ph2y5i9UaKrMqOOrgzePxK01C3ciZM14ElIARQ37gUrl6/idQFg/D9tw3hVhX+ xZzPXi8F2VHKeF+WbvQ1oD0lzD2KobZ/5senhisPUdwEWVaX/xbVVV3sT+JFm8n0 7PMEDX39GGGfriVR1W2aOtUTJvkCCcOqdT91lvxWjLOmClEorjdRQevOqvVIlIMB jQb66FsWmLA4SmpABwBLHESyKnRBUFR1R1IZrtBUMeehW2MCwNg7v5Fr++6IYzRm OELFTvKIOQdajSoR3+wfzCb25M2NIs60ZH1n/5pgdfu3BkoQLaCBklDceNJnS2bG WTThZMJ5/ZM++MpVFjoMLvZY0SZC7+BsDehIFX1bOe5oZw33JnZdGOPyJBMtvRGL nURHKAtF2To793rnW4d2 =Tdbg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context parameter override?
2014-09-10 21:52 GMT+04:00 sbre...@hotmail.com: (...) What puzzles me is the Context / Parameter feature of Tomcat. (context-param from Java is clear.) There are at least 3 locations to define Tomcat level parameters: - server.xml / Host (1) - webapps / ... / context.xml (2) - conf/.../myapp.xml (3) None of these I managed to configure. (1) - wrong. You should not define a Context there. In Tomcat 6 that you are using, the META-INF/context.xml file (2) is automatically copied into conf directory of Tomcat (3) when the web application is being deployed. Once that copying happens modifying the webapp's file (2) becomes useless. You have to modify the copy. This copyXml feature was turned off starting with Tomcat 7. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context parameter override?
I am pretty sure I tried option 3 and Log4j initialization did ignore my log4jConfigLocation setting in conf/.../myapp.xml. What I tried to see in the debug log is the list of context parameters picked up at start time. Despite log level was set to FINEST nothing show up in any of the Tomcat logs related to my parameter declaration. I shall look into the Tomcat code to understand this. Date: Thu, 11 Sep 2014 00:20:19 +0400 Subject: Re: Context parameter override? From: knst.koli...@gmail.com To: users@tomcat.apache.org 2014-09-10 21:52 GMT+04:00 sbre...@hotmail.com: (...) What puzzles me is the Context / Parameter feature of Tomcat. (context-param from Java is clear.) There are at least 3 locations to define Tomcat level parameters: - server.xml / Host (1) - webapps / ... / context.xml (2) - conf/.../myapp.xml (3) None of these I managed to configure. (1) - wrong. You should not define a Context there. In Tomcat 6 that you are using, the META-INF/context.xml file (2) is automatically copied into conf directory of Tomcat (3) when the web application is being deployed. Once that copying happens modifying the webapp's file (2) becomes useless. You have to modify the copy. This copyXml feature was turned off starting with Tomcat 7. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: record security manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Wim, On 9/10/14 9:36 AM, Wim Bertels wrote: as i tested setup debian + tomcat7 following the documentation, i was refered to http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html for enabling the security manager, as it seems in debian stable (with tomcat + examples + admin debian packages installed): - enabling the security manager: tomcat does not start What do the logs say? You probably have SecurityExceptions logged somewhere. -- the logs are not clear to me Can you paste a segment, or better yet, the whole thing after a clean start? This is not a tomcat problem, but debian it seems to me. Tomcat itself should start properly under a security manager. Your web application might not have the proper configuration to run under a security manager, but your web application failing to start should not cause Tomcat to fail to start. It's important to get the logs. Can you find them? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUEMj3AAoJEBzwKT+lPKRYKg8P/1a2FfL/DsttO6TVZv6ocFhM +7JQ5jRrSDuJLu8AIklmhi/L5POty0LMU4R4vQj2opmfU6PA7I/+ERh6pcrBvGMr skIq+DZiaSi+fHRX1jIOYUaqcG28li+8t8UsdBmgxw6LWLgSmhK9CA7XcXfqzFJ+ W4inN0ImTPSps9EgM8GgPtzbbVn7ZKFDoi5Xc9cp1ublBxnpcm1eoZLcyIPojiIQ jLTKTc603TxC8UflrwRJNPsR7WxOsLrCETt/pVsHN8qYLEwjDqc42k5V5Y/HXSLj gajmoOeRV9FczcELWxJvrOFiXX+uS9ASIQQZcag+SMZTLwJPl78I+eHIMdOMZjte Te6wDhHRNJXunAa9JadYfMOmb91s0HLy452ZbZ+Ah4pqImcJVPcRf5ZSYC3PsA2u wMhe2zZkyGlGaIMVEqZaYQxFM1/0/hIIGbrmOGkkX1tE2CLojdxaugMcaqmfmDZ8 GOLgCefwFy8PtxTOdtwyq/gh1xprRyCgMonumWKyjf6m4x/qi02iyk4hQc5TkB1H 3x7pRv1EDbhqUPGCJ/70S1dAsfnQaYuATHiLgGrlS0p71tEdf7F6IlQ6GDt98mwG smhE4Uqnh3ZiV5FQDlHZAxG5kN9gnfAO0d7Lql6pkKOTnzpwpR8GmbAqOmhX/W21 NuXefYCTjvHjNCtnRhVo =ERmX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context parameter override?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Responses inline. On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote: I am pretty sure I tried option 3 and Log4j initialization did ignore my log4jConfigLocation setting in conf/.../myapp.xml. Oh heck, I think I see what you're trying to do. And this isn't going to work for multiple web applications, since it's a SYSTEM property. This means you get 1 value for the JVM. The following web page illustrates this: http://logging.apache.org/log4j/1.2/manual.html Read the section called Default Initialization under Tomcat. Also, what you're configuring is a context initialization parameter with Parameter and NOT a system property. In short, if you're trying to direct log4j to read the log4j.xml (or properties) file from another location, setting a context initialization parameter will get you absolutely nowhere. What I tried to see in the debug log is the list of context parameters picked up at start time. Despite log level was set to FINEST nothing show up in any of the Tomcat logs related to my parameter declaration. I shall look into the Tomcat code to understand this. It's not an issue with the Tomcat code. It's how log4j goes about finding its configuration file. log4j uses Thread.getContextClassLoader().getResource() to find the log4j.xml (or properties) file. This means that the file must be in your classpath. In Tomcat, the search works its way up the class loader hierarchy. See the following link for how the class loaders are searched. http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html If you want the following: 1. per-application control over log4j logging 2. run-time (as in while the application is running) control 3. thread safety, reliability, and no thread leaks You will need to do the following: 1. implement a JMX listener to publish the log levels 2. set reasonable levels in log4j.xml found in the context's classpath 3. use a JMX utility to change the log levels during operation If you want the following: 1. per-application control over log4j logging 2. change log levels while the application is not running Then you have some options (and I hope you start / stop logging in a servlet context listener). Place the log4j.xml (or properties) file in the WAR file. When it's deployed (if the WAR is exploded), you can then edit it and restart the context. Place the log4j.xml (or properties) file outside the WAR file and do the following (again, this will have to be facilitated by the Dev group): 1. Create a context init parameter (most easily in the Parameter element in context.xml). 2. The init parameter will give the path to the file 3. Read that parameter in a servlet context listener 4. Pass that to the Configurator's configure(String filename) method Again, you will have to tell log4j to find the configuration some place other than it normally looks (classpath or the SYSTEM property log4j.configuration). Here's how I manage things. 1. Maven project for deploy a. accepts a parameter to select appropriate logging levels b. this selects a properties file to filter a log4j template c. properties file is under version control d. accepts a parameter for the version to deploy e. accepts a parameter for where to deploy 2. Parameterized Jenkins job a. runs the Maven project b. drop-down menu for IT (internal test), UAT, PROD c. drop-down menu for version (no SNAPSHOTS in PROD!) d. sends email to dev responsible, ops, business lead 1. what was deployed 2. where it was deployed 3. when it was deployed 4. who deployed it (no shared accounts on Jenkins) I use parallel deployment with Tomcat 7 and use the Jenkins build number to increment the value. I'm working on updating the incident tracking system automatically from Jenkins, but I'm just learning Groovy and the tracking system doesn't have a robust API. . . . just my two cents /mde/ Date: Thu, 11 Sep 2014 00:20:19 +0400 Subject: Re: Context parameter override? From: knst.koli...@gmail.com To: users@tomcat.apache.org 2014-09-10 21:52 GMT+04:00 sbre...@hotmail.com: (...) What puzzles me is the Context / Parameter feature of Tomcat. (context-param from Java is clear.) There are at least 3 locations to define Tomcat level parameters: - server.xml / Host (1) - webapps / ... / context.xml (2) - conf/.../myapp.xml (3) None of these I managed to configure. (1) - wrong. You should not define a Context there. In Tomcat 6 that you are using, the META-INF/context.xml file (2) is automatically copied into conf directory of Tomcat (3) when the web application is being deployed. Once that copying happens modifying the webapp's file (2) becomes useless. You have to modify the copy. This copyXml feature was turned off starting with Tomcat 7. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUENScAAoJEEFGbsYNeTwt+lwH/iUxrY8FoVTmK2hK4ewPOhNs
Re: Context parameter override?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/10/14 6:45 PM, Mark Eggers wrote: Responses inline. On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote: I am pretty sure I tried option 3 and Log4j initialization did ignore my log4jConfigLocation setting in conf/.../myapp.xml. Oh heck, I think I see what you're trying to do. And this isn't going to work for multiple web applications, since it's a SYSTEM property. This means you get 1 value for the JVM. The following web page illustrates this: http://logging.apache.org/log4j/1.2/manual.html If the OP is using log4j with multiple web applications and wants to have log4j.jar at the Tomcat level instead of at the webapp level, then log4j 2.x is what he wants: it's got much better support for things like multiple ClassLoaders, etc. Using default initialization for log4j is just a Bad Idea in general. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIbBAEBCAAGBQJUEONXAAoJEBzwKT+lPKRYvtMP8wZZjCGcyHty/R3gDQWsfh+N 3D4A+V0sRGi2xNb4uEpdwd7yRRAc6m7D8IRodzJfYM2mLCKLl4vZxzbcGyfX3+H8 OHpRy9dD9g33QhFIGtz2DBjGx4O0dZbF9Crjt9BsVbMORPwQgS0Z8rxgEj3nSXzp uR1E/9Cyv0WOsKMjkIGFrdvRvyibipaJ6q3/uKzBmhGsk9LdBlUhzzN6YpYnkV1M S5Ca2wosTTEDmzapL34dI7OtjnZNgfl4egqD9u2aMvARTlQMfVG6A1v/LRVhXbDU AtQSxCrspbEeVZQjyTxADWrh/3eAQXehaaRrfej/gHoEZKNhxMqDvbmFFhHwl2YZ upFWiWSWOP4xBbA4pHnstd0lp6zSygO7mXjZPYfeW9V/Qac1FBM784UQWtq9V1RO s0eeyhknLYcIr8d55EXMXZ1KDbtpGOC/2qXwZMPktsk+CQNyUwBiNa9BR6GQxGr2 mMGr3LbDVM/cfTNmmbTR5YQVnt4CyausF/Wrgo2WKCpD2fL8Kc4yxG6g1d9tqk0j MkPSn9UKjhEXgFDSpf+3Fyf5GrPK3z+QTAt5xU9rYf1x6jIocRuxCgx7bLpuUplH Pj9b0OeJMELrJtvBCCEWDjpCKdPwcLGQVJBTe5i2jH0/9P3/1lTLU+xrDbat7CCJ qTo97nFTnd9FwoSnazM= =HLyL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context parameter override?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 9/10/2014 4:48 PM, Christopher Schultz wrote: Mark, On 9/10/14 6:45 PM, Mark Eggers wrote: Responses inline. On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote: I am pretty sure I tried option 3 and Log4j initialization did ignore my log4jConfigLocation setting in conf/.../myapp.xml. Oh heck, I think I see what you're trying to do. And this isn't going to work for multiple web applications, since it's a SYSTEM property. This means you get 1 value for the JVM. The following web page illustrates this: http://logging.apache.org/log4j/1.2/manual.html If the OP is using log4j with multiple web applications and wants to have log4j.jar at the Tomcat level instead of at the webapp level, then log4j 2.x is what he wants: it's got much better support for things like multiple ClassLoaders, etc. Using default initialization for log4j is just a Bad Idea in general. -chris Agreed. However since the original poster is running under Tomcat 6, I went ahead and assumed (insert appropriate comment here) that the included library was 1.2.x. If it's 2.x, then my comments should be factored accordingly. So B, which version of log4j is being included in your applications? Are you using one log4j JAR in $CATAINA_HOME/lib (or $CATALINA_BASE/lib)? . . . discovery, it's not just for breakfast anymore /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUEOWQAAoJEEFGbsYNeTwtXmUH/3HrbaTGrvgSGdY7lWZk/I/y 6LKBNWyxVSHkdn4XhIJryDd1h6UihnA90Z+3UlOwc3jyKh95zdlqYj32cDs+tEeQ Qlhjz7UlT5JYPRVjp4ksK/PQ6S9sgFefB+gXWABVBsawlpy0f/tiWknKuMyGVGFM eEEX+aghV/hj6qI8u31KyaxwCjnxv4E+EQ+hBZ5ZkW/ElmNlMf1gI/uF+sDAL2LI eQ/1MD24DzkpU/lJZ0nCbj3L+YwP+lACOQlyZW8ptHSHgnGLwcW8Se+JrHF09/qD wmmOkXyNtKXiFj2wvCwF49Wle1FcCCmOJqUj4e9zTiAf5jlIjtfkPNLQ7wXkqYY= =PVAv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Problem with Dynamic .war Deployment
Hello, If I deploy my servlet statically, it runs fine. When I deploy dynamically, I get what looks like a classpath error. The dependency for this class org.bouncycastle.jce.X509Principal is located within the .war file at WEB-INF/lib/bcprov-jdk15on-1.50.jar, and other libraries such as a JDBC driver are loaded and run correctly, but this error occurs. I've tried deploying this servlet in Tomcat 7, 8.0.5, and 8.0.12. Here is the stack trace: java.lang.IllegalArgumentException: unknown object in getInstance: org.bouncycastle.jce.X509Principal at org.bouncycastle.asn1.ASN1Sequence.getInstance(Unknown Source) ~[ASN1Sequence.class:1.50.0] at org.bouncycastle.asn1.x500.X500Name.getInstance(Unknown Source) ~[X500Name.class:1.50.0] at net.test.crypto.X509CryptoUtils.signCertificateRequest(X509CryptoUtils.java:225) ~[X509CryptoUtils.class:na] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_20] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_20] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_20] at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0_20] at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) [ResourceMethodInvocationHandlerFactory$1.class:na] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151) [AbstractJavaResourceMethodDispatcher$1.class:na] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171) [AbstractJavaResourceMethodDispatcher.class:na] at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152) [JavaResourceMethodDispatcherProvider$ResponseOutInvoker.class:na] at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104) [AbstractJavaResourceMethodDispatcher.class:na] at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387) [ResourceMethodInvoker.class:na] at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331) [ResourceMethodInvoker.class:na] at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103) [ResourceMethodInvoker.class:na] at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271) [ServerRuntime$1.class:na] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [Errors$1.class:na] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [Errors$1.class:na] at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [Errors.class:na] at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [Errors.class:na] at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [Errors.class:na] at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297) [RequestScope.class:na] at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254) [ServerRuntime.class:na] at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028) [ApplicationHandler.class:na] at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:372) [WebComponent.class:na] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:382) [ServletContainer.class:na] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:345) [ServletContainer.class:na] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:220) [ServletContainer.class:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) [catalina.jar:8.0.5] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:8.0.5] at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat-websocket.jar:8.0.5] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) [catalina.jar:8.0.5] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:8.0.5] at org.apache.catalina.filters.CorsFilter.handleNonCORS(CorsFilter.java:439) [catalina.jar:8.0.5] at org.apache.catalina.filters.CorsFilter.doFilter(CorsFilter.java:178) [catalina.jar:8.0.5] at
stress testing tomcat applications
Hi, I am working on a stress tester for my application, however, from within the stress tester, sometimes it loses the sessionid An overview of the process is 1. login to application and get sessionid 2. send subsequent requests to server that sessionid 3. Repeat steps 1 and 2 for multiple users The problem is that in my server logs, I occasionally get a message saying a client connected with an unrecognized sessionid, ie one that has no logged in yet My best guess is that tomcat doesnt like to accept requests coming for two different logins from the same IP and same program. Is that accurate? Is anything else that could be going wrong here?
Deploy application as Root
Hi, I am trying to deploy application as ROOT.war in tomcat 7.50 provided by hosting service provider, but for some reasons I get below message FAIL - War file ROOT.war cannot be uploaded if context is defined in server.xml I have below in server xml, Host name=Myapp.com appBase=path to public_html folder Aliaswww.myapp.com/Alias Aliasmyuserid.myhostingprovider.com/Alias Context path= reloadable=true docBase= path to public_html debug=1/ Context path=/manager debug=0 privileged=true docBase=path to /tomcat/webapps/manager /Context /Host However the ROOT.war gets deployed correctly in my local machine.Appreciate some help here for fixing this issue. - Kiran
RE: Context parameter override?
We have Log4j packaged within the WAR for each of the deployed applications. Under run-time configuration I mean editing the standard log4j.xml which is re-read by Tomcat. (I.e. we do not want to reimplement any log level configuration in servlet configuraton, what we want is to pass the location of that log4j file outside the WAR and be able to change this location without touching the webapps directory, otherwise we will lose it with redeployment.) What worked perfectly is the log4jConfigLocation context-param in the web.xml. As far as I understand this mechanism comes from Spring (class Log4jWebConfigurer), which is fine, as all our applications use Spring. What does not work is to override log4jConfigLocation from the conf/.../myapp.xml context file (after Tomcat copies it there) using the Parameter element. Anyone experience with this exact problem? Or, how to debug it? Date: Wed, 10 Sep 2014 16:58:08 -0700 From: its_toas...@yahoo.com.INVALID To: users@tomcat.apache.org Subject: Re: Context parameter override? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 9/10/2014 4:48 PM, Christopher Schultz wrote: Mark, On 9/10/14 6:45 PM, Mark Eggers wrote: Responses inline. On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote: I am pretty sure I tried option 3 and Log4j initialization did ignore my log4jConfigLocation setting in conf/.../myapp.xml. Oh heck, I think I see what you're trying to do. And this isn't going to work for multiple web applications, since it's a SYSTEM property. This means you get 1 value for the JVM. The following web page illustrates this: http://logging.apache.org/log4j/1.2/manual.html If the OP is using log4j with multiple web applications and wants to have log4j.jar at the Tomcat level instead of at the webapp level, then log4j 2.x is what he wants: it's got much better support for things like multiple ClassLoaders, etc. Using default initialization for log4j is just a Bad Idea in general. -chris Agreed. However since the original poster is running under Tomcat 6, I went ahead and assumed (insert appropriate comment here) that the included library was 1.2.x. If it's 2.x, then my comments should be factored accordingly. So B, which version of log4j is being included in your applications? Are you using one log4j JAR in $CATAINA_HOME/lib (or $CATALINA_BASE/lib)? . . . discovery, it's not just for breakfast anymore /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUEOWQAAoJEEFGbsYNeTwtXmUH/3HrbaTGrvgSGdY7lWZk/I/y 6LKBNWyxVSHkdn4XhIJryDd1h6UihnA90Z+3UlOwc3jyKh95zdlqYj32cDs+tEeQ Qlhjz7UlT5JYPRVjp4ksK/PQ6S9sgFefB+gXWABVBsawlpy0f/tiWknKuMyGVGFM eEEX+aghV/hj6qI8u31KyaxwCjnxv4E+EQ+hBZ5ZkW/ElmNlMf1gI/uF+sDAL2LI eQ/1MD24DzkpU/lJZ0nCbj3L+YwP+lACOQlyZW8ptHSHgnGLwcW8Se+JrHF09/qD wmmOkXyNtKXiFj2wvCwF49Wle1FcCCmOJqUj4e9zTiAf5jlIjtfkPNLQ7wXkqYY= =PVAv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
