What's the Attic
Hi,
Just commited
src/share/org/apache/tomcat/service/connector/Ajp13ConnectorResponse and I
saw =
Did I broke something ?
-
hgomez 00/12/12 01:41:45
Modified:src/share/org/apache/tomcat/service/connector Tag: tomcat_32
Ajp13ConnectionHandler.java
Ajp13ConnectorRequest.java
Ajp13ConnectorResponse.java
JNIConnectionHandler.java MsgBuffer.java
MsgConnector.java TcpConnector.java
Log:
Fix the multiple cookies bug with ajp13, PR 371
Revision ChangesPath
No revision
No revision
1.4.2.1 +3 -3
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13Conn
ectionHandler.java
Index: Ajp13ConnectionHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectionHandler.java,v
retrieving revision 1.4
retrieving revision 1.4.2.1
diff -u -r1.4 -r1.4.2.1
--- Ajp13ConnectionHandler.java 2000/06/15 10:14:44 1.4
+++ Ajp13ConnectionHandler.java 2000/12/12 09:41:43 1.4.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectionHandler.java,v 1.4 2000/06/15 10:14:44 shachor Exp $
- * $Revision: 1.4 $
- * $Date: 2000/06/15 10:14:44 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectionHandler.java,v 1.4.2.1 2000/12/12 09:41:43 hgomez Exp $
+ * $Revision: 1.4.2.1 $
+ * $Date: 2000/12/12 09:41:43 $
*
*
*
1.5.2.2 +3 -3
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13Conn
ectorRequest.java
Index: Ajp13ConnectorRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectorRequest.java,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- Ajp13ConnectorRequest.java2000/11/15 12:03:00 1.5.2.1
+++ Ajp13ConnectorRequest.java2000/12/12 09:41:43 1.5.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectorRequest.java,v 1.5.2.1 2000/11/15 12:03:00 hgomez Exp $
- * $Revision: 1.5.2.1 $
- * $Date: 2000/11/15 12:03:00 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectorRequest.java,v 1.5.2.2 2000/12/12 09:41:43 hgomez Exp $
+ * $Revision: 1.5.2.2 $
+ * $Date: 2000/12/12 09:41:43 $
*
*
*
1.4.2.3 +8 -8
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13Conn
ectorResponse.java
Index: Ajp13ConnectorResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectorResponse.java,v
retrieving revision 1.4.2.2
retrieving revision 1.4.2.3
diff -u -r1.4.2.2 -r1.4.2.3
--- Ajp13ConnectorResponse.java 2000/11/28 21:36:51 1.4.2.2
+++ Ajp13ConnectorResponse.java 2000/12/12 09:41:44 1.4.2.3
@@ -1,8 +1,8 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectorResponse.java,v 1.4.2.2 2000/11/28 21:36:51 craigmcc Exp $
- * $Revision: 1.4.2.2 $
- * $Date: 2000/11/28 21:36:51 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic
/Ajp13ConnectorResponse.java,v 1.4.2.3 2000/12/12 09:41:44 hgomez Exp $
+ * $Revision: 1.4.2.3 $
+ * $Date: 2000/12/12 09:41:44 $
*
*
*
@@ -130,18 +130,18 @@
headers.removeHeader("Status");
headers.removeHeader("Servlet-Engine");
-msg.appendInt(headers.size());
+ int numHeaders = headers.size();
+ msg.appendInt(numHeaders);
-Enumeration e = headers.names();
-while(e.hasMoreElements()) {
-String headerName = (String)e.nextElement();
+ for( int i=0 ; i numHeaders ; i++ ) {
+ String headerName = headers.getHeaderName(i);
int sc = headerNameToSc(headerName);
if(-1 != sc) {
msg.appendInt(sc);
} else {
msg.appendString(headerName);
}
-msg.appendString(headers.getHeader(headerName));
+msg.appendString(headers.getHeader(i));
RE: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +1 I'll still be for security updates but release a 3.1.1 could make some users thinking the 3.1 tree is still alive. Could be disturbing some days after 3.2 release. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. + 1 I've also fixed ajp13/multiples cookies. Will it be included ?
Re: Problem to limit the number of connections
Actually, the version of tomcat I use is 3.1. Could this explain that it does not work? Arieh Markel a écrit : Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: moderator for [EMAIL PROTECTED] From: Sophie Lemonnier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Problem to limit the number of connections X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Hello, I have a machine with little ressouces and with other applications than tomcat are running. Consequently, I would like to prevent too many clients to connect to tomcat... I haven't managed yet to limit the number of connections Can anyone help me? Sophie, you did not mention the version of Tomcat that you are using. In any case, I believe that for 3.2, the solution is in properties for the org.apache.tomcat.service.PoolTcpConnector class: the properties below control the number of threads (which will be associated with inbound socket connections) that the connector has. public static final String THREAD_POOL = "thread_pool"; public static final String MAX_THREADS = "max_threads"; public static final String MAX_SPARE_THREADS = "max_spare_threads"; public static final String MIN_SPARE_THREADS = "min_spare_threads"; What you need to do is modify your server.xml to explicitly set the property values that are appropriate for you: (Here is an example from an old server.xml I was using) Connector className="org.apache.tomcat.service.PoolTcpConnector" Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/ Parameter name="port" value="8180"/ Parameter name="thread_pool" value="on"/ Parameter name="max_threads" value="100"/ Parameter name="max_spare_threads" value="30"/ Parameter name="min_spare_threads" value="10"/ /Connector Arieh -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key)
HELP ! building mod_jk with fdatasync...
Hello, I am trying to run tomcat 3.2 with apache 1.3 on Solaris 2.6. I can make the mod_jk.so by apxs -o mod_jk.so -DSOLARIS -I../jk -I/usr/java/include -I/usr/java/include/solaris -c *.c ../jk/*.c and then run gcc -shared -o mod_jk.so *.o I receive the error "symbol fdatasync: referenced symbol not found" at run time ( as predicted by the homepage...) so I follow the instruction placing -lposix4 just in front of -c. BUT IT DOESN'T WORK!!! Anyone can HELP? Daniel
Missing Content-Length-Header using AJP13
Hello, I'm using Tomcat 3.2 (final version) in combination with Apache 1.3.14 and mod_jk. Switching to Ajpv13 protocol two problems concerning the HTTP-Header occur: 1) Content-Length-Field header is missing 2) After status-code 200 the "OK" is missing Using Ajpv12 protocol the HTTP-Header looks fine. Best regards Markus Dr. Markus Bode kippdata gmbh Tel.: 0228/9854916 Bornheimer Str. 33a Fax: 0228/9854950 53111 Bonn e-mail: [EMAIL PROTECTED]
RE: What's the Attic
Did I broke something ? No, the attic is where CVS left files present in previous versions but deleted in the head branch, Saludos , Ignacio J. Ortega
RE: Missing Content-Length-Header using AJP13
Thanks to give more informations (eventually sample code). I've patched ajp13 for bug with multiples cookies. I'm not sure it could fix your problem... "Pour la plupart des hommes, se corriger consiste à changer de défauts." -- Voltaire
BugRat Report #568 has been filed.
Bug report #568 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/568 REPORT #568 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: Win 2000, Linux OS Release: 5 Platform: ? Synopsis: Form based authentication gives 404 - File not found error. Description: When you access the form directly (most often done by bookmarking it) and not by accessing a protected area first, after submitting the username and password Tomcat returns a 404 error. This because it does not know which page to send after the user has been authenticated. The result is that a null is appended to the end of the url and this does not exist. Title: BugRat Report # 568 BugRat Report # 568 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Allan Schweitz ([EMAIL PROTECTED]) Date Submitted: Dec 12 2000, 05:54:12 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Form based authentication gives 404 - File not found error. Environment: (jvm, os, osrel, platform) 1.3, Win 2000, Linux, 5, ? Additional Environment Description: n.a. Report Description: When you access the form directly (most often done by bookmarking it) and not by accessing a protected area first, after submitting the username and password Tomcat returns a 404 error. This because it does not know which page to send after the user has been authenticated. The result is that a null is appended to the end of the url and this does not exist. How To Reproduce: null Workaround: null View this report online...
BugRat Report #570 has been filed.
Bug report #570 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/570 REPORT #570 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: all Operating System: all OS Release: all Platform: all Synopsis: http/ https detection failes when exporting JkEnvVar xxx yyy Description: using the parameter JkEnvVar xxx yyy to submit environment variables from Apache to Tomcat causes tomcat to set scheme always to https and secure Title: BugRat Report # 570 BugRat Report # 570 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Heinz Richter ([EMAIL PROTECTED]) Date Submitted: Dec 12 2000, 06:46:41 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: http/ https detection failes when exporting JkEnvVar xxx yyy Environment: (jvm, os, osrel, platform) all, all, all, all Additional Environment Description: Report Description: using the parameter JkEnvVar xxx yyy to submit environment variables from Apache to Tomcat causes tomcat to set scheme always to https and secure How To Reproduce: null Workaround: null View this report online...
RE: used bugrat but not all fields filled
Thnaks to indicate your apache version (mod_ssl/ssl) and the export flags. The ajp13 is under heavy fire and many fixes are underway. "Pour la plupart des hommes, se corriger consiste à changer de défauts." -- Voltaire -Original Message- From: Heinz Richter [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 12, 2000 1:54 PM To: [EMAIL PROTECTED] Subject: used bugrat but not all fields filled report 571 not complete === === -- http/ https detection failes when exporting JkEnvVar xxx yyy using the parameter JkEnvVar xxx yyy to submit environment variables from Apache to Tomcat causes tomcat to set scheme always to https and secure How To Reproduce (optional): use JkEnvVar xxx yyy in httpd.conf and look at SnoopServlet output should report: Scheme: http Request Is Secure: false Known Work Around org.apache.tomcat.service.connector; public class Ajp13ConnectorRequest comment out line: case SC_A_REQ_ATTRIBUTE : === //isSSL = true; attributes.put(msg.getString(), msg.getString()); break; === === The workaround and reproduce field was not taken by bugrat HWR
BugRat Report #571 has been filed.
Bug report #571 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/571 REPORT #571 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: all Operating System: all OS Release: all Platform: all Synopsis: http/ https detection failes when exporting JkEnvVar xxx yyy Description: using the parameter JkEnvVar xxx yyy to submit environment variables from Apache to Tomcat causes tomcat to set scheme always to https and secure Title: BugRat Report # 571 BugRat Report # 571 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Heinz Richter ([EMAIL PROTECTED]) Date Submitted: Dec 12 2000, 06:48:06 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: http/ https detection failes when exporting JkEnvVar xxx yyy Environment: (jvm, os, osrel, platform) all, all, all, all Additional Environment Description: . Report Description: using the parameter JkEnvVar xxx yyy to submit environment variables from Apache to Tomcat causes tomcat to set scheme always to https and secure How To Reproduce: null Workaround: null View this report online...
used bugrat but not all fields filled
report 571 not complete == -- http/ https detection failes when exporting JkEnvVar xxx yyy using the parameter JkEnvVar xxx yyy to submit environment variables from Apache to Tomcat causes tomcat to set scheme always to https and secure How To Reproduce (optional): use JkEnvVar xxx yyy in httpd.conf and look at SnoopServlet output should report: Scheme: http Request Is Secure: false Known Work Around org.apache.tomcat.service.connector; public class Ajp13ConnectorRequest comment out line: case SC_A_REQ_ATTRIBUTE : === //isSSL = true; attributes.put(msg.getString(), msg.getString()); break; == The workaround and reproduce field was not taken by bugrat HWR
[TC 4 m4] How can I build ?
Hi, I cannot download JMX (Java Management Extensions), because I reside outside USA. But TC4 needs JMX. How can I build TC4 ? Thanks, Kim
BugRat Report #573 has been filed.
Bug report #573 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/573 REPORT #573 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.2 final JVM Release: 1.3 Operating System: Solaris OS Release: 7 Platform: Sparc Synopsis: setting error-pagelocation to an html file causes a stack overflow Description: In my web.xml: error-page error-code404/error-code location/foo.html/location /error-page error-page exception-typejava.lang.NullPointerException/exception-type location/foo.html/location /error-page I've verified that foo.html loads correctly. If I try to access a non-existent page, or access a servlet which throws a NullPointerException, I get the following stack trace in my browser: java.lang.StackOverflowError at java.lang.StringBuffer.expandCapacity(StringBuffer.java:195) at java.lang.StringBuffer.append(StringBuffer.java:401) at java.io.FileNotFoundException.(FileNotFoundException.java:62) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:64) at java.io.FileInputStream.(FileInputStream.java:95) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:365) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) This repeats for quite a while. Title: BugRat Report # 573 BugRat Report # 573 Project: Tomcat Release: 3.2 final Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Kief Morris ([EMAIL PROTECTED]) Date Submitted: Dec 12 2000, 08:46:01 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: setting to an html file causes a stack overflow Environment: (jvm, os, osrel, platform) 1.3, Solaris, 7, Sparc Additional Environment Description: Report Description: In my web.xml: 404 /foo.html java.lang.NullPointerException /foo.html I've verified that foo.html loads correctly. If I try to access a non-existent page, or access a servlet which throws a NullPointerException, I get the following stack trace in my browser: java.lang.StackOverflowError at java.lang.StringBuffer.expandCapacity(StringBuffer.java:195) at java.lang.StringBuffer.append(StringBuffer.java:401) at java.io.FileNotFoundException.(FileNotFoundException.java:62) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:64) at java.io.FileInputStream.(FileInputStream.java:95) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:365) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1049) at org.apache.tomcat.request.FileHandler.doService(StaticInterceptor.java:387) This repeats for quite a while. View this report online...
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
"Craig R. McClanahan" wrote: Over the last three days, a review of published and soon-to-be-published reports of security vulnerabilities in Tomcat has uncovered a series of problems in the 3.1 final release, and a couple of less serious (but still significant) problems in 3.2. Please vote (quickly) on the following two issues: Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +1 Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. Very shortly I will have some updated documents for configuring Tomcat to use the Java SecurityManager under various flavors of MS Windows. I would like to get this into the 3.2.1 release. +1 If you can hold off a day so I can get these documents updated Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: Missing Content-Length-Header using AJP13
I take a look at ajp13 code and Status/Servlet-Engine headers are removed before response to apache server.
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2 From: Jon Stevens [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N on 12/11/2000 5:59 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. They can upgrade to 3.1.1 but not 3.2? Huh? Yes, that is actually the situation. I can tell you that in our application, the changes implied by moving from 3.1 to 3.2 were significant (we use Tomcat in an embedded manner, dynamically incorporating servlets to contexts), mainly because there were implementation differences in the APIs (for Contexts, facades, etc). No, make people upgrade to 3.2. There are WAY to many advantages to having 3.2. We cannot 'make people upgrade'. There are organizations that rely on a certain revision of the software. The decision of upgrading or not is not only hinged on the advantages but in the drawbacks (the time to regression-test that the application still functions, the time to spend to verify that the change is 'transparent', etc), therefore, there are going to be users that will not upgrade to 3.2 but will be willing to move to 3.1.1. I would argue that a move from 3.1 to 3.1.1 falls into the category of transparent move, while not being able to say the same of moving from 3.1 to 3.2. Arieh -jon -- Honk if you love peace and quiet. -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key)
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request SimpleMapper1.java StaticInterceptor.java
The fix is incorrect.
indexOf returns -1 when the substring is not found, not 0.
The way the current code is set forces wrong behavior.
It should be:
(relativePath.indexOf("/META-INF/") != -1) ||
(relativePath.indexOf("/WEB-INF/") != -1))
Arieh
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request
SimpleMapper1.java
StaticInterceptor.java
craigmcc00/12/11 09:52:31
Modified:src/share/org/apache/tomcat/request Tag: tomcat_32
SimpleMapper1.java StaticInterceptor.java
Log:
Fix a security vulnerability that would display the contents of sensitive
files when a URL like this was used:
http://localhost:8080/examples//WEB-INF/web.xml
This vulnerability appears on Linux (and any other OS that ignores "//" in
the middle of a pathname), but not on Windows.
Submitted by: Ramon Cacha [EMAIL PROTECTED]
PR: BugRat Bug Report #565
Revision ChangesPath
No revision
No revision
1.15.2.4 +2 -2
jakarta-tomcat/src/share/org/apache/tomcat/request/SimpleMapper1.java
Index: SimpleMapper1.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/SimpleMapper1.java,v
retrieving revision 1.15.2.3
retrieving revision 1.15.2.4
diff -u -r1.15.2.3 -r1.15.2.4
--- SimpleMapper1.java 2000/12/01 03:00:41 1.15.2.3
+++ SimpleMapper1.java 2000/12/11 17:52:30 1.15.2.4
@@ -343,8 +343,8 @@
requestURI.substring(contextPath.length()).toUpperCase();
if (relativePath.equals("/META-INF") ||
relativePath.equals("/WEB-INF") ||
-relativePath.startsWith("/META-INF/") ||
-relativePath.startsWith("/WEB-INF/"))
+(relativePath.indexOf("/META-INF/") != 0) ||
+(relativePath.indexOf("/WEB-INF/") != 0))
return 404;
return OK;
1.7.2.5 +3 -1
jakarta-tomcat/src/share/org/apache/tomcat/request/StaticInterceptor.java
Index: StaticInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/StaticInterceptor.java,v
retrieving revision 1.7.2.4
retrieving revision 1.7.2.5
diff -u -r1.7.2.4 -r1.7.2.5
--- StaticInterceptor.java 2000/11/07 22:52:52 1.7.2.4
+++ StaticInterceptor.java 2000/12/11 17:52:30 1.7.2.5
@@ -418,7 +418,9 @@
String relPathU=relPath.toUpperCase();
if ( relPathU.startsWith("WEB-INF") ||
- relPathU.startsWith("META-INF")) {
+ relPathU.startsWith("META-INF") ||
+(relPathU.indexOf("/WEB-INF/") != 0) ||
+(relPathU.indexOf("/META-INF/") != 0) ) {
return null;
}
}
--
Arieh Markel Sun Microsystems Inc.
Network Storage500 Eldorado Blvd. MS UBRM11-194
e-mail: [EMAIL PROTECTED] Broomfield, CO 80021
Let's go Panthers Phone: (303) 272-8547 x78547
(e-mail me with subject SEND PUBLIC KEY to get public key)
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
I have to agree with Arieh on this one. Coming from an organization that has a very rigerous change management process I know that it can take upwards of 4 months to release a piece of software, let alone a server upgrade that is not just a security fix. If it adds features above and beyond the current rev then all of the parties with applications or code on that server have to be notified and they have to submit change management requests for testing etc Imagine a coders hell ... and you have change management. I think a 3.1.1 release makes sence but I also think it is important in the release notes that we not only tell them that it is important that they attempt to get on the latest rev of tomcat (3.2.1 in this case) but if we can also make some suggestions on how they can start changing their coding now to prepare for the 4.0 transition. I am not sure if that is easier said then done but it is a suggestions ... Sean - Original Message - From: "Arieh Markel" [EMAIL PROTECTED] I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. They can upgrade to 3.1.1 but not 3.2? Huh? Yes, that is actually the situation. I can tell you that in our application, the changes implied by moving from 3.1 to 3.2 were significant (we use Tomcat in an embedded manner, dynamically incorporating servlets to contexts), mainly because there were implementation differences in the APIs (for Contexts, facades, etc). No, make people upgrade to 3.2. There are WAY to many advantages to having 3.2. We cannot 'make people upgrade'. There are organizations that rely on a certain revision of the software. The decision of upgrading or not is not only hinged on the advantages but in the drawbacks (the time to regression-test that the application still functions, the time to spend to verify that the change is 'transparent', etc), therefore, there are going to be users that will not upgrade to 3.2 but will be willing to move to 3.1.1. I would argue that a move from 3.1 to 3.1.1 falls into the category of transparent move, while not being able to say the same of moving from 3.1 to 3.2. Arieh -jon -- Honk if you love peace and quiet. -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key)
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
[EMAIL PROTECTED] 12/11/00 06:19PM Over the last three days, a review of published and soon-to-be-published reportsof security vulnerabilities in Tomcat has uncovered a series of problems in the3.1 final release, and a couple of less serious (but still significant) problemsin 3.2. Please vote (quickly) on the following two issues:Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems. . . . +1Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problemsplus the patches committed to date.. . . +1 If possible, I would like to see the two patches that I posted (and sent to Craig) for NetWare in the 3.2.1 build. They only affect the native connectors on NetWare, but there are several people inside and outside of Novell that are starting to use Tomcat 3.2. If not, I'll try and keep as many of these as I know about up to date with what I build until the patches are checked in. Either way, security fixes are more important. Craig Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com
cvs commit: jakarta-tomcat/src/doc JDBCRealm.howto
nacho 00/12/12 08:49:38 Modified:src/doc Tag: tomcat_32 JDBCRealm.howto Log: BugReport# 567 Missing JDBCRealm classes from Tomcat Implementation? Submitted by Anonymous Revision ChangesPath No revision No revision 1.3.2.1 +2 -2 jakarta-tomcat/src/doc/Attic/JDBCRealm.howto Index: JDBCRealm.howto === RCS file: /home/cvs/jakarta-tomcat/src/doc/Attic/JDBCRealm.howto,v retrieving revision 1.3 retrieving revision 1.3.2.1 diff -u -r1.3 -r1.3.2.1 --- JDBCRealm.howto 2000/06/19 21:39:53 1.3 +++ JDBCRealm.howto 2000/12/12 16:49:36 1.3.2.1 @@ -86,7 +86,7 @@ 3. Add the information to the server.xml file. For this example I used this entry: -RequestInterceptor className="org.apache.tomcat.realm.JDBCRealm" debug="99" +RequestInterceptor className="org.apache.tomcat.request.JDBCRealm" debug="99" driverName="org.gjt.mm.mysql.Driver" connectionURL="jdbc:mysql://localhost/authority?user=test;password=test" userTable="users" userNameCol="user_name" userCredCol="user_pass" @@ -116,7 +116,7 @@ - If you have problem connecting you can specify connectionName and connectionPassword: -RequestInterceptor className="org.apache.tomcat.realm.JDBCRealm" +RequestInterceptor className="org.apache.tomcat.request.JDBCRealm" debug="99" driverName="oracle.jdbc.driver.OracleDriver" connectionURL="jdbc:oracle:thin:@ntserver:1521:ORCL"
BugRat Report #567 was closed (apparently by: Ignacio Ortega)
Report #567 was closed by Person #0 Synopsis: Missing JDBCRealm classes from Tomcat Implementation? (logged in as: Ignacio Ortega)
Re: Compiling JSP's with debugging info in Tomcat 3.3
Larry Isaacs wrote: In addition to specifying these JSP options, I'm looking for a way to alter the defaults that get used when these options aren't specified in server.xml. My target is to be able run Tomcat in debugging and non-debugging situations using the same server.xml and without modifying server.xml to switch. Not having to ask the user to modify server.xml helps avoid a potential source of errors and avoids the need to document it for someone who might not be familiar with Tomcat. So far, my best guess is to support a JSP defaults string like that described in the earlier e-mail and obtain this string from a System property, or perhaps a command line argument. My preference would be as a System property. One thing you should keep in mind, on the general issue of debugging information, is that there is a Java Specification Request (JSR-045) currently under way which will standardize mechanisms for storing debugging information for non-Java languages that are translated into Java source code -- JSPs being an obvious example -- into the class files themselves. Jasper in the 4.x tree is going to track the results of that effort when they come out. You can get more information about JSR-045 at the Java Community Process web site http://java.sun.com/jcp. Cheers, Larry Craig
Re: HELP ! building mod_jk with fdatasync...
On Tue, 12 Dec 2000, jackie wrote: Hello, I am trying to run tomcat 3.2 with apache 1.3 on Solaris 2.6. I can make the mod_jk.so by apxs -o mod_jk.so -DSOLARIS -I../jk -I/usr/java/include -I/usr/java/include/solaris -c *.c ../jk/*.c and then run gcc -shared -o mod_jk.so *.o I receive the error "symbol fdatasync: referenced symbol not found" at run time ( as predicted by the homepage...) so I follow the instruction placing -lposix4 just in front of -c. BUT IT DOESN'T WORK!!! When I compiled it on Solaris, I also had to put the -lposix4 in the gcc arguments as well. I did it like this: gcc -shared -lposix4 -o mod_jk.so *.o Michael Grinder
Re: [TC 4 m4] How can I build ?
Kief Morris wrote: Pilho Kim typed the following on 23:23 12/12/2000 +0900 I cannot download JMX (Java Management Extensions), because I reside outside USA. I was able to download it from here (UK) without any problem. I had to register, but it worked. The "README.txt" file in Tomcat 4.0 was recently clarified to cover one confusing point -- you need the "JMX Instrumentation and Agent Reference Implementation" (current version number is 1.0) from http://java.sun.com/products/JavaManagement/download.html. There is a separate download called the "JMX Reference Implementation" which does not have everything that Tomcat needs. Kief Craig
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper Constants.java
Danno Ferrin wrote: I think that keeping the import list to what is required by the spec and refrencing all of the other object we need to compile by the fully qualified name will result in less un-intended colissions. +1 for importing exactly, and only, the "default import list" defined in the JSP 1.2 spec (p. 47). Craig
Re: BugRat Report #574 has been filed.
Synopsis:
Browser issues a "document contains no data" when a secure page is accessed
by an valid, unauthorized user (wrong role).
I tested with my HTTP client, and got that :
[Slide]$ get /webdav/
snip
Request: GET /webdav/ HTTP/1.1
GET /webdav/ HTTP/1.1
Content-Length: 0
Authorization: Basic cm9vdDpyb290
cookie: $Version=1
host: 127.0.0.1:8080
user-agent: org.apache.webdav.lib.WebdavClient
HTTP/1.1 403 Access to the requested resource has been denied
Response: HTTP/1.1 403 Access to the requested resource has been denied
Content-Length: 0
Date: Tue, 12 Dec 2000 18:10:55 GMT
Server: Apache Tomcat/4.0-dev (HTTP/1.1 Connector)
Connection: close
Closing connection
Status: 403
I was using an incorrect role ("root", and "tomcat" was expected). I got a
403 back (which is normal). We don't return an error page in that particular
case (this error is returned by the authenticator valve), so that's why you
see no data.
Remy
BugRat Report #575 has been filed.
Bug report #575 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/575
REPORT #575 Details.
Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment:
Release: Tomcat 3.2 Final
JVM Release: 1.1.8
Operating System: AIX
OS Release: 4.3.3
Platform: PowerPC
Synopsis:
AdaptiveClassLoader leaks file descriptors
Description:
Under JDK 1.1.8, the AdaptiveClassLoader leaks file
descriptors from the getResource method. This gets invoked
( among other times ) every time Beans.instantiate is called
with the servlet classloader instead of null ( it tries to
find a serialized bean before creating a default instance ).
The ZipFile object used to look in jars found in the
repository list is never explicitly closed ( and the finalize
method doesn't seem to do it either ). The solution is
to close the ZipFile in a finally block. Each time this
method runs and searches a zip file ( or jar ), it will leak
one file descriptor for each file it processes ( we have 10
jars in our WEB-INF/lib so that's 10 file descriptors for
each hit to a page with one jsp:useBean ). A patch follows:
--- jakarta-tomcat-3.2.orig/src/org/apache/tomcat/loader/AdaptiveClassLoader.java
Wed Nov 29 20:47:52 2000
+++ jakarta-tomcat-3.2/src/org/apache/tomcat/loader/AdaptiveClassLoader.javaTue
+Dec 12 13:47:05 2000
@@ -804,8 +804,9 @@
// a jar:-URL *could* change even between minor releases, but
// didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from
// IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris
+ZipFile zf = null;
try {
-ZipFile zf = new ZipFile(file.getAbsolutePath());
+zf = new ZipFile(file.getAbsolutePath());
ZipEntry ze = zf.getEntry(name);
if (ze != null) {
@@ -819,6 +820,8 @@
} catch (IOException ioe) {
ioe.printStackTrace();
return null;
+} finally {
+if ( zf != null ) try { zf.close(); } catch ( IOException e ) { }
}
}
}
Title:
BugRat Report #
575
BugRat Report #
575
Project:
Tomcat
Release:
Tomcat 3.2 Final
Category:
Bug Report
SubCategory:
New Bug Report
Class:
swbug
State:
received
Priority:
high
Severity:
critical
Confidence:
public
Submitter:
Joel Bartley ([EMAIL PROTECTED])
Date Submitted:
Dec 12 2000, 01:18:45 CST
Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])
Synopsis:
AdaptiveClassLoader leaks file descriptors
Environment: (jvm, os, osrel, platform)
1.1.8, AIX, 4.3.3, PowerPC
Additional Environment Description:
Report Description:
Under JDK 1.1.8, the AdaptiveClassLoader leaks file
descriptors from the getResource method. This gets invoked
( among other times ) every time Beans.instantiate is called
with the servlet classloader instead of null ( it tries to
find a serialized bean before creating a default instance ).
The ZipFile object used to look in jars found in the
repository list is never explicitly closed ( and the finalize
method doesn't seem to do it either ). The solution is
to close the ZipFile in a finally block. Each time this
method runs and searches a zip file ( or jar ), it will leak
one file descriptor for each file it processes ( we have 10
jars in our WEB-INF/lib so that's 10 file descriptors for
each hit to a page with one jsp:useBean ). A patch follows:
--- jakarta-tomcat-3.2.orig/src/org/apache/tomcat/loader/AdaptiveClassLoader.java Wed Nov 29 20:47:52 2000
+++ jakarta-tomcat-3.2/src/org/apache/tomcat/loader/AdaptiveClassLoader.javaTue Dec 12 13:47:05 2000
@@ -804,8 +804,9 @@
// a jar:-URL *could* change even between minor releases, but
// didn't between JVM's 1.1.6 and 1.3beta. Tested on JVM's from
// IBM, Blackdown, Microsoft, Sun @ Windows and Sun @ Solaris
+ZipFile zf = null;
try {
-ZipFile zf = new ZipFile(file.getAbsolutePath());
+zf = new ZipFile(file.getAbsolutePath());
ZipEntry ze = zf.getEntry(name);
if (ze != null) {
@@ -819,6 +820,8 @@
} catch (IOException ioe) {
ioe.printStackTrace();
return null;
+} finally {
+if ( zf != null ) try { zf.close(); } catch ( IOException e ) { }
}
}
}
View this report online...
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Tomcat 3.2 final has the following security vulnerabilities that have subsequently been fixed in the CVS repository: * A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can expose sensitive information (note the double slash after "examples"). * The "Show Source" custom tag used to display JSP source code can be used to expose sensitive information in WEB-INF. I was not privi to a few of the original posts regarding this. Is the vulnerability only exposed if one can access the tomcat port directly? So if I blocked all access to say port 9090 (where my tomcat port is) from any foreign machines, then it is safe? Or is the vulnerability exposed even when accessing tomcat via apache port 80? -- Freddie Mendoza [EMAIL PROTECTED]
unsubscribe tomcat-dev
unsubscribe tomcat-dev = Cengiz Kayay WebObjects/JAVA Consultant __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
[PATCH] src/org/apache/tomcat/service/LocalStrings.properties
Added some missing HTTP response lines which weren't in my 3.2 tree. At least 423 is needed for Webdav. --- LocalStrings.properties.old Wed Nov 29 20:47:44 2000 +++ LocalStrings.properties Wed Dec 13 05:57:52 2000 @@ -66,9 +66,15 @@ sc.415=Unsupported Media Type sc.416=Requested Range Not Satisfiable sc.417=Expectation Failed +sc.422=Unprocessable Entity +sc.423=Locked +sc.424=Failed Dependency sc.500=Internal Server Error sc.501=Not Implemented sc.502=Bad Gateway sc.503=Service Unavailable sc.504=Gateway Timeout sc.505=HTTP Version Not Supported +sc.506=Variant Also Varies +sc.507=Insufficient Storage +sc.510=Not Extended
Monitoring tomcat
What is the best method to monitor the thread number (busy, ready etc.) in ThreadPool? I've changed the class /org/apache/tomcat/util/ThreadPool (just add two methods getCurrent... and one threads that writes out result). Now, has anyone similar need? Is there any possibility to add that feature in new realise of tomcat(logging or jsp page such as server-status in apache)? Kresimir -- Iskon internet e-mail servis - http://webmail.iskon.hr/
BugRat Report #578 has been filed.
Bug report #578 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/578 REPORT #578 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.2 JVM Release: any Operating System: any OS Release: any Platform: any Synopsis: RequestDispatcher includes automatically commit response Description: It looks like in the 3.2 release, a call to RequestDispatcherImpl.include() always calls response.flushBuffer(), which in turn always commits the response. This means that once you have included a servlet that only manipulates a request and not the response, you can't forward to another servlet to finish the job. Title: BugRat Report # 578 BugRat Report # 578 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Jonathan Bass ([EMAIL PROTECTED]) Date Submitted: Dec 12 2000, 05:15:32 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: RequestDispatcher includes automatically commit response Environment: (jvm, os, osrel, platform) any, any, any, any Additional Environment Description: Report Description: It looks like in the 3.2 release, a call to RequestDispatcherImpl.include() always calls response.flushBuffer(), which in turn always commits the response. This means that once you have included a servlet that only manipulates a request and not the response, you can't forward to another servlet to finish the job. How To Reproduce: null View this report online...
nsapi redirector for solaris
Hello All, I am having problems with the netscape redirector shared object, nsapi_redirector.so I have Netscape Enterprise Server 3.6 and Tomcat 3.1 on Solaris 2.7 I was able to compile the redirector, nsapi_redirector.so However, after modifying netscape's obj.conf for tomcat redirection, am not able to start netscape server. I get this message "In jk_init" and then netscape server exits. If someone has got netscape-tomcat working on Solaris, could you please send me your nsapi_redirector.so Also do I need to do any setup outside of what's given in the netscape-howto. Would greatly appreciate any response. Thanks. Mukul
RE: [ANNOUNCEMENT] Security Related Updates - Tomcat 3.1.1 and Tomcat 3.2.1
Has there been a definitive list of these security problems with TC 3.1 or TC 3.2? What are the "appropriate contents" of the $TOMCAT_HOME directory that I need to replace for both TC 3.1 and TC 3.2? Aron Kramlik. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 12, 2000 4:32 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Security Related Updates - Tomcat 3.1.1 and Tomcat 3.2.1 Recent investigations and reports have revealed security vulnerabilities in both Tomcat 3.1 and Tomcat 3.2 final releases. To deal with these problems, the Tomcat team has developed maintenance releases, and recommended actions, for each major version. (Tomcat 4.0 milestone 4 shares one of these vulnerabilities that will be fixed in the upcoming milestone 5 release, which is imminent.) TOMCAT 3.1 USERS * There are seven identified vulnerabilities that are documented in the Release Notes for Tomcat 3.1.1 (file "doc/readme" in the distribution). * To deal with these problems for users who are unable to upgrade, a maintenance release, Tomcat 3.1.1, has been prepared. You can download it at: http://jakarta.apache.org/builds/tomcat/release/v3.1.1/bin/ * This release fixes ***only*** the identified security vulnerabilities. It does not address any of the other bugs that exist in Tomcat 3.1. No future maintenance release of Tomcat 3.1 is planned to deal with these issues. * You are ***strongly*** encouraged to upgrade to Tomcat 3.2.1 as quickly as possible. In doing so, you will benefit from these security vulnerabilities being fixed, performance improvements, new features, and a large number of non-security related bug fixes. See below for the download URL. * In the event that you are not able to upgrade immediately, the corrective action is to download the binary distribution, and replace the appropriate contents in the $TOMCAT_HOME directory. There is no need to modify any of the binary components (such as the mod_jserv component used to connect Tomcat to Apache). * In addition, if you have not removed it already (or built your own security mechanisms to protect it), you should remove the Tomcat 3.1 administrative application by deleting the $TOMCAT_HOME/webapps/admin directory. TOMCAT 3.2 USERS * There are two identified vulnerabilities that are documented in the Release Notes for Tomcat 3.2.1 (file "doc/readme" in the distribution). These vulnerabilities have been fixed in Tomcat 3.2.1. * You can download this security maintenance release at: http://jakarta.apache.org/builds/tomcat/release/v3.2.1/bin/ * You are ***strongly*** encouraged to download and install this update as quickly as possible. * This release fixes ***only*** the identified security vulnerabilities. It does not address any of the other bugs, or feature requests, related to Tomcat 3.2 final. These issues will be dealt with in future maintenance releases of Tomcat 3.2 as appropriate. * The corrective action is to download the binary distribution, and replace the appropriate contents in the $TOMCAT_HOME directory. There is no need to modify any of the binary components (such as the mod_jserv component used to connect Tomcat to Apache). Craig McClanahan
BugRat Report #581 has been filed.
Bug report #581 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/581
REPORT #581 Details.
Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: critical
Confidence: public
Environment:
Release: 3.2
JVM Release: 1.2.2-6
Operating System: Compaq Tru64
OS Release: v4.0f
Platform: Unix
Synopsis:
Tomcat does not launch with given Unix script files
Description:
When launching Tomcat using ./startup.sh or ./tomcat.sh, the background process never
runs because it complains of invalid parameters being passed on the command line.
Perform all necessary steps on Compaq Tru64 v4.0f and simply type in (from
$TOMCAT_HOME):
./bin/startup.sh
To fix you must edit the tomcat.sh file (located in $TOMCAT_HOME/bin) and remove the
double quotes (") around each and EVERY instance of $@. So instead of seeing a line
as the following:
$JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} org.apache.tomcat.startup.Tomcat
"$@"
You should have:
$JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} org.apache.tomcat.startup.Tomcat
$@
The reason for this is that somehow an empty parameter is being passed to Tomcat and
it is continually complaining an invalid parameter was sent and subsequently displays
the usage info.
Title:
BugRat Report #
581
BugRat Report #
581
Project:
Tomcat
Release:
3.2
Category:
Bug Report
SubCategory:
New Bug Report
Class:
swbug
State:
received
Priority:
medium
Severity:
critical
Confidence:
public
Submitter:
Kristopher Kycia ([EMAIL PROTECTED])
Date Submitted:
Dec 12 2000, 06:33:13 CST
Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])
Synopsis:
Tomcat does not launch with given Unix script files
Environment: (jvm, os, osrel, platform)
1.2.2-6, Compaq Tru64, v4.0f, Unix
Additional Environment Description:
Report Description:
When launching Tomcat using ./startup.sh or ./tomcat.sh, the background process never runs because it complains of invalid parameters being passed on the command line.
Perform all necessary steps on Compaq Tru64 v4.0f and simply type in (from $TOMCAT_HOME):
./bin/startup.sh
To fix you must edit the tomcat.sh file (located in $TOMCAT_HOME/bin) and remove the double quotes (") around each and EVERY instance of $@. So instead of seeing a line as the following:
$JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} org.apache.tomcat.startup.Tomcat "$@" &
You should have:
$JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} org.apache.tomcat.startup.Tomcat $@ &
The reason for this is that somehow an empty parameter is being passed to Tomcat and it is continually complaining an invalid parameter was sent and subsequently displays the usage info.
View this report online...
Re: [ANNOUNCEMENT] Security Related Updates - Tomcat 3.1.1 and Tomcat 3.2.1
Aron Kramlik wrote: Has there been a definitive list of these security problems with TC 3.1 or TC 3.2? The definitive lists of what vulnerabilities were fixed are in the release notes document for each version (file "doc/readme" in the download). Subscribers to TOMCAT-DEV also saw the CVS commits that included the fixes for these problems, so that you can also see *how* they were fixed. Look for the "tag" modifier to tell you which version was being updated by any particular patch. What are the "appropriate contents" of the $TOMCAT_HOME directory that I need to replace for both TC 3.1 and TC 3.2? The details depend on how you've deployed Tomcat, and whether or not you've kept any of the applications that were shipped. Perhaps the simplest approach is to simply replace the entire contents of your TOMCAT_HOME directory and they redeploy all of your applications in it (and restore customizations to things like "conf/servler.xml") -- but it's hard to be specific, given the variety of approaches people take. The key point, though, is that you do *not* have to recompile or reinstall the native code web connector modules in order to install these updates. Aron Kramlik. Craig
Re: JSSE redistribution
Aaron Knauf wrote: Is there any reason why we can't compile tomcat against JSSE and include the jars in the tomcat lib directory as part of the standard binary distribution? This would make it much easier for people to get HTTPS support from tomcat. I believe that the Sun licence allows for redistribution, and US law allows us foreigners to get at the crypto stuff, now. Although the rules have been relaxed considerably, the US export regulations still require preventing anyone from certain countries from downloading this stuff. If JSSE was distributed in Tomcat, that would mean that we (Apache) would be held responsible for enforcing that restriction -- and this would most likely require some sort of click-through mechanism on *everyone* who downloads (plus a bunch of lawyer time to make sure all the rules were being followed). There is also still paperwork involved in registering as a distributor of encryption materials -- even though it's legal. I seem to remember seeing a post about this a while ago, but I never saw a resolution. If there are no objections, I move that we include JSSE as part of standard tomcat. Given that the restriction above exists, I'm afraid I can't see us doing this at the current time. Cheers Craig McClanahan
BugRat Report #580 was closed (apparently by: Nick Bauman)
Report #580 was closed by Person #0 Synopsis: Tomcat does not launch with given Unix script files (logged in as: Nick Bauman)
BugRat Report #582 was closed (apparently by: Nick Bauman)
Report #582 was closed by Person #0 Synopsis: cannot send more than 8K to the servlet (logged in as: Nick Bauman)
BugRat Report #577 was linked to Bug #62(apparently by:Nick Bauman)
BugRat Report #577 was linked to Bug #62 (logged in as:Nick Bauman)
[ANNOUNCEMENT] Security Related Updates - Tomcat 3.1.1 and Tomcat 3.2.1
Recent investigations and reports have revealed security vulnerabilities in both Tomcat 3.1 and Tomcat 3.2 final releases. To deal with these problems, the Tomcat team has developed maintenance releases, and recommended actions, for each major version. (Tomcat 4.0 milestone 4 shares one of these vulnerabilities that will be fixed in the upcoming milestone 5 release, which is imminent.) TOMCAT 3.1 USERS * There are seven identified vulnerabilities that are documented in the Release Notes for Tomcat 3.1.1 (file "doc/readme" in the distribution). * To deal with these problems for users who are unable to upgrade, a maintenance release, Tomcat 3.1.1, has been prepared. You can download it at: http://jakarta.apache.org/builds/tomcat/release/v3.1.1/bin/ * This release fixes ***only*** the identified security vulnerabilities. It does not address any of the other bugs that exist in Tomcat 3.1. No future maintenance release of Tomcat 3.1 is planned to deal with these issues. * You are ***strongly*** encouraged to upgrade to Tomcat 3.2.1 as quickly as possible. In doing so, you will benefit from these security vulnerabilities being fixed, performance improvements, new features, and a large number of non-security related bug fixes. See below for the download URL. * In the event that you are not able to upgrade immediately, the corrective action is to download the binary distribution, and replace the appropriate contents in the $TOMCAT_HOME directory. There is no need to modify any of the binary components (such as the mod_jserv component used to connect Tomcat to Apache). * In addition, if you have not removed it already (or built your own security mechanisms to protect it), you should remove the Tomcat 3.1 administrative application by deleting the $TOMCAT_HOME/webapps/admin directory. TOMCAT 3.2 USERS * There are two identified vulnerabilities that are documented in the Release Notes for Tomcat 3.2.1 (file "doc/readme" in the distribution). These vulnerabilities have been fixed in Tomcat 3.2.1. * You can download this security maintenance release at: http://jakarta.apache.org/builds/tomcat/release/v3.2.1/bin/ * You are ***strongly*** encouraged to download and install this update as quickly as possible. * This release fixes ***only*** the identified security vulnerabilities. It does not address any of the other bugs, or feature requests, related to Tomcat 3.2 final. These issues will be dealt with in future maintenance releases of Tomcat 3.2 as appropriate. * The corrective action is to download the binary distribution, and replace the appropriate contents in the $TOMCAT_HOME directory. There is no need to modify any of the binary components (such as the mod_jserv component used to connect Tomcat to Apache). Craig McClanahan
cvs commit: jakarta-tomcat-4.0/catalina/docs JDBCRealm-howto.html JDBCRealm.howto
nacho 00/12/12 08:59:29
Added: catalina/docs JDBCRealm-howto.html
Removed: catalina/docs JDBCRealm.howto
Log:
BugReport# 567
Missing JDBCRealm classes from Tomcat Implementation?
Submitted by Anonymous
Revision ChangesPath
1.1 jakarta-tomcat-4.0/catalina/docs/JDBCRealm-howto.html
Index: JDBCRealm-howto.html
===
html
link rel="stylesheet" href="style.css"
style type="text/css"
td {
background-color: #E0E0E0;
vertical-align: text-top;
}
th {
background-color: #d0d0d0;
}
table {
width: 75%;
background-color: #00;
}
/style
titleWorking with JDBCRealm/titlebody
h1Working with JDBCRealm/h1
h2What is JDBCRealm?/h2
pIs an implementation of a tomcat 3.X Realm that use a set of configurable tables
inside a RDMS to store user's data, this tables are accessed by means of standard
JDBC drivers.br
The passwords can be stored as digested ( using standard Java's MessageDigest ) or
in plain form.br
All the parameters, drivers, tables, and columns are user configurable. /p
h2Example Config for JDBCRealm/h2
This is an example of how to set up a JDBC Realm. For this example I used the MySQL
JDBC driver.
h31. Create a database. /h3
blockquote
p I made the database named "authority"/p
/blockquote
h3 2. Create needed tables. /h3
blockquote
h4 1. The user table. /h4
blockquote
pThis table needs the user's name and a password field. In the example I
use "users" for the table name, "user_name" for the column that holds the
user's name, and "user_pass" for the user's password. /p
/blockquote
h42. The role table. /h4
blockquote
pThis table needs the role's set up that will be in any deployment
descriptor that is managed under the container this Realm is in. In the
example I use "roles" as the table name and "role_name" as the role's name.
NB: This table doesn't get used at all by tomcat. /p
/blockquote
h43. The role to user table. /h4
blockquote
pThis table joins a set of roles to a single user. In the example the
table name is "user_roles", the role's name is "role_name" , and the user's
name is assumed to have the same column name as in the user's table
("user_name" in this example. /p
pHere is the SQL I used to create the tables:
/p
/blockquote
/blockquote
table align="center"
tr
td
precreate table users
(
user_name varchar(15) not null primary key,
user_pass varchar(15) not null
);
create table roles
(
role_name varchar(15) not null primary key
);
create table user_roles
(
user_name varchar(15) not null,
role_name varchar(15) not null,
primary key( user_name, role_name )
);
/pre
/td
/tr
/table
blockquote
blockquote
pbr
Here is sample output from the tables:
br
br
/p
/blockquote
/blockquote
table align="center" border="0"
tr
td
pre
mysql select * from users;
+---+---+
| user_name | user_pass |
+---+---+
| tomcat| tomcat|
| user1 | tomcat|
| user2 | tomcat|
| user3 | tomcat|
+---+---+
4 rows in set (0.00 sec)
mysql
mysql select * from roles;
++
| role_name |
++
| tomcat |
| role1 |
++
2 rows in set (0.02 sec)
mysql
mysql select * from user_roles;
++---+
| role_name | user_name |
++---+
| tomcat | user1 |
| role1 | user2 |
| tomcat | tomcat|
| role1 | tomcat|
++---+
4 rows in set (0.00 sec)
mysql
/pre
/td
/tr
/table
h33. Configure Tomcat /h3
blockquote
pAdd the information to the server.xml file. For this example I usedthis entry
inside: /p
/blockquote
table width="100%" border="0" align="center"
tr
td
blockquote
pcodebr
lt;RequestInterceptor
className="org.apache.catalina.realm.JDBCRealm"br
debug="99"
driverName="org.gjt.mm.mysql.Driver" br
connectionURL="jdbc:mysql://localhost/authority?user=test;password=test"
userTable="users"br
userNameCol="user_name"br
userCredCol="user_pass"br
userRoleTable="user_roles"
roleNameCol="role_name" /gt;
br
/code/p
/blockquote
/td
/tr
/table
pThe meaning of the attributes is as follow:/p
table align="center" width="51%"
tr
th height="32"
pattribute/p
/th
thMeaning/th
/tr
tr
td height="32" driverName/td
td height="32" The name of the driver needed to connect to the database
/td
/tr
tr
