Re: CGI support servlet (TC 4) -- feedback wanted
Craig R. McClanahan wrote: On Mon, 2 Apr 2001, Amy Roh wrote: Hi Martin, See comments below. Martin Dengler wrote: [snip] 1) Name, Package, and Inner Classes: Name: Current name is CGIGatewayServlet. The rationale is "this is the first name I thought of." Would we prefer CGIInvokerServlet? I personally prefer CGIInvokerServlet than CGIGatewayServlet since CGIGatewayServlet sounds kind of redundant (because it is CGI(Common Gateway Interface) GatewayServlet. This doesn't matter much though. I would be just as happy with CGIServlet (and SSIServlet for that matter). But org.apache.catalina.servlets is definitely the right package. Agreed with these and other comments I received on the redundancy point. Both CGIServlet and CGIInvokerServlet sound good to me. I can change it to CGIServlet and see how that works. [snip] Inner Classes: The CGIGatewayServlet.java file has one main class and [...] BIG +1 for separating those inner classes and putting them in org.apache.catalina.util.cgi. It will be a LOT easier to maintain. I did this already for myself to review your code. I can send them to you if you want to save a little time. :-) +0 -- I'm not hung up on inner classes, but do not have any problem if others want them separated. Hmm, yeah I thought people might generally find it slightly preferable. I'm generally +0, but sounds like it would be useful. I will probably leave it a couple more days before I bring them out, just to get the various class responsibilities bedded down. Especially the exec functionality (Bip and I are getting together on this for both SSI/CGI) would be reusable or at least easiest maintained outside as its own class(es). 2) Addition to default context Would this CGI servlet be added to the default context similar to SsiInvokerServlet? Yes. I would suggest that we do this, but leave it commented out. The reason is that the potential for mischief is *much* larger when we are talking about executing outside programs instead of just displaying content back to a web browser. I vote for making the Tomcat sysadmin have to enable this feature explicitly if they want it. Once we implement the #exec functionality in SSI, the same argument would apply here -- unless we added a config option to disable the #exec by default but left everything else alone. An alternative (possibly additional) approach would be to tweak the security manager properties so that executing external programs is *not* allowed by default. That way, we could leave these two servlets defined in the conf/web.xml file, but they won't be able to cause damage. +1 on both counts. Does that imply that for out-of-the-box Tomcat, maybe some CGI examples wouldn't work? That's certainly not a bad thing, but it brings a couple of additional ideas to mind: 1) we leave the servlet in catalina's web.xml commented out and the security manager restrictive as suggested; or 2) As #1 above but also include the servlet definition mapping in the examples webapp's web.xml, with the servlet smart enough to display a useful message if the security manager restricts access. That way the servlet examples would produce meaningful behavior out-of-the-box, but the security restriction on running outside programs is still in place. The admin would have to explicitly enable any such wild-and-crazy functionality. 3) Providing Examples Would it be appropriate to provide some links in the examples webapp along with an example cgi script? I would have thought so... YES. In fact, could you send me some? Of course, such things are going to be platform-specific ... be sure to include examples for Windows as well as Unix platforms. Good point, I guess I should provide: 1) Unix shell example (using #!/bin/sh) 2) Windows batch (*.bat) 3) Unix perl (using #!/usr/local/bin/perl, assume perl 4 only) 4) Windows perl (*.pl; would this alone work though??) 5) Default location of cgi scripts In another project, we have put all cgi scripts under webapp/WEB-INF/cgi since they are then 1) not liable to be served by the container; yet 2) still encapsulated underneath the webapp's own directory structure. One observation and two issues here: Observation: the Servlet spec is obviously silent on CGI placement issues; yet we should probably support (and even default to?) something congruent with standard CGI practice of separating the HTML and CGI scripts (/doc-root and /cgi-bin) while not encouraging anything which breaks the Servlet API's web application filesystem (or war file) boundaries. Issue 1) generally, how do people like the webapp/WEB-INF/cgi solution in light of the above observation? +1 One thing to keep in mind is that this won't work if the webapp is run directly from a WAR file unless you go to interesting lengths to extract these scripts from the WAR
Re: CGI support servlet (TC 4) -- feedback wanted
Amy, Thanks for the feedback; see comments inline. Martin Amy Roh wrote: Hi Martin, See comments below. Martin Dengler wrote: [snip] If so, would people prefer I do that myself and submit a load of file patches for the commit of the CGI servlet related files which included the catalina web.xml? This is a minor issue adding a few lines to catalina web.xml. I have done this already on my CVS tree. Cool, I will include that as part of my submission. 4) Providing Functional testing classes I was wondering if and how I should add any testing cgi scripts. I have some (obviously :)), but should they be put into the tester area because they are for testing, or should I reuse some examples webapp (above issue #2) cgi scripts? Any issues with this dependency? We can put them into tester area so we can run tester if/when we add/modify CGI feature. Could you send me these scripts as well? Right now they are basically the same scripts that I added to the examples webapp. So, should I just duplicate the scripts so we have one set in tomcat-root/webapps/examples/WEB-INF/cgi-bin and one set in tomcat-root/tester/src/bin? Or would the tester/src/bin/tester.xml simply have some targets which tested the output of some requests to http://server/examples/cgi-bin/cgitester.cgi, etc.? 5) Default location of cgi scripts In another project, we have put all cgi scripts under webapp/WEB-INF/cgi since they are then 1) not liable to be served by the container; yet 2) still encapsulated underneath the webapp's own directory structure. One observation and two issues here: Observation: the Servlet spec is obviously silent on CGI placement issues; yet we should probably support (and even default to?) something congruent with standard CGI practice of separating the HTML and CGI scripts (/doc-root and /cgi-bin) while not encouraging anything which breaks the Servlet API's web application filesystem (or war file) boundaries. Issue 1) generally, how do people like the webapp/WEB-INF/cgi solution in light of the above observation? +1 Cool. Issue 2) if people like it, should we make it the default setting (by defining an init-parameter for the CGI servlet in the container-wide web.xml file)? I think we should designate a cgi directory where people can put CGI scripts for security reasons. Yes, on a per-webapp level? Is the source code from http://www.martindengler.com/proj/CGIGatewayServlet.zip the most updated one? I have made some more updates which I have not posted yet. Once I take into account your others' suggestions, I will update that zip file. I imagine I can make most of the changes tonight and re-package tomorrow, so hopefully a new one will be up soon. Amy Thanks for all the feedback. Martin
Re: CGI support servlet (TC 4) -- feedback wanted
Mel Martinez wrote: --- Bip Thelin [EMAIL PROTECTED] wrote: [snip] +1 on having CGI in web.xml but commented out, regarding SSI I suggest we add a configure property(like Apaches NoExec) that set's whether #exec is allowed or not. And if that property is not set it defaults to NoExec. So for a standard setup SSI would be allowed but you'd have to bug your Tomcat sysadmin to have the #exec option enabled. Sort of like a standard Apache setup. ..bip +1 on what Bip said. Cool -- regardless of the security manager settings we decide on, I will submit with the web.xml entry commented out as requested. mel Chrs, Martin
RE: Tomcat 4.0-beta-2 Security Vulnerability
I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? I vote you just call it "Tomcat-4.0-beta-3". I don't recall ever being told there were limits to the number of betas one can produce. :-) I believe that a new beta number is justified by any significant bug fix or fixes and a security hole is definitely significant, even if the code change may be tiny. +1 for Tomcat-4.0-beta-3 And what about including in TC 4.0b3 my patches which help build tc 4.0 on non standard distro, ie jsse.jar not in JSSE_HOME/lib or jmxri.jar not in JMX_HOME/lib.
cvs commit: jakarta-tomcat/src/doc mod_jk-howto.html
hgomez 01/04/02 23:47:34 Modified:src/doc mod_jk-howto.html Log: Correct documentation since in mod_jk warn log level didn't exist, use info instead (half-close BUG #332) Add info about JkLogStampFormat directive Revision ChangesPath 1.7 +11 -10jakarta-tomcat/src/doc/mod_jk-howto.html Index: mod_jk-howto.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/mod_jk-howto.html,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- mod_jk-howto.html 2001/03/15 16:23:12 1.6 +++ mod_jk-howto.html 2001/04/03 06:47:33 1.7 @@ -62,10 +62,8 @@ ul lia href="#s61"mod_jk Binaries/a/li lia href="#s62"Building mod_jk/a/li -lia href="#s63"Building mod_jk - for NT/a/li -lia href="#s64"Building mod_jk - for Unix/a/li +lia href="#s63"Building mod_jk for NT/a/li +lia href="#s64"Building mod_jk for Unix/a/li /ul /li lia href="#s7"Configuring Apache/a @@ -77,8 +75,7 @@ lia href="#s8"Configuring Tomcat/a ul lia href="#s81"Enabling Tomcat's Apache Auto-Config/a/li -lia href="#s82"Configuring Tomcat to use the - AJPv13 Protocol/a/li +lia href="#s82"Configuring Tomcat to use the AJPv13 Protocol/a/li lia href="#s83"Defining Workers/a/li /ul /li @@ -509,9 +506,12 @@ Use mod_jk's ttJkWorkersFile/tt configuration directive./li liYou should specify a location where mod_jk is going to place its log file and a log level to be used. Use the ttJkLogFile/tt and ttJkLogLevel/tt - configuration directives. Possible log levels are idebug/i, iwarn/i, - ierror/i and iemerg/i, but iwarn/i should be your default + configuration directives. Possible log levels are idebug/i, iinfo/i, + ierror/i and iemerg/i, but iinfo/i should be your default selection./li + liThe directive ttJkLogStampFormat/tt will configure the date/time format + found on mod_jk logfile. Using ttstrftime()/tt format string it's set by + default to "[%a %b %d %H:%M:%S %Y] "/li /ul A simple example would be to include the following lines in your tthttpd.conf/tt file: blockquotepre @@ -519,7 +519,8 @@ AddModule mod_jk.c JkWorkersFile /usr/local/jakarta-tomcat/conf/workers.properties JkLogFile /usr/local/apache/logs/mod_jk.log -JkLogLevelwarn +JkLogLevelinfo +JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " /pre/blockquote /div @@ -739,7 +740,7 @@ # JkWorkersFile /usr/local/jakarta-tomcat/conf/jk/workers.properties JkLogFile /usr/local/apache/logs/mod_jk.log -JkLogLevelwarn +JkLogLevelinfo # First Virtual Host. #
Tomcat 4.0-beta-3 Released (SECURITY VULNERABILITY)
Tomcat 4.0-beta-3 is an update to the Tomcat 4.0-beta-2 distribution that was released on 30 March 2001. It fixes a further security vulnerability related to potentially exposing JSP source that was only partially corrected in beta 2. Anyone using versions of Tomcat 4.0 earlier than the beta 3 release (or the nightly build dated 20010403 or later) is strongly encouraged to immediately update to the beta 3 release. Craig McClanahan
context factories
I've read in a post by Remy with subject: "Re: ejb-ref ejb-link
Implementation in 4.0.b1",
http://w4.metronet.com/~wjm/tomcat/2001/Mar/msg00273.html that the only
two factories supported in tomcat right now is one for getting Tyrex
managed data sources User Transactions.
I'm interested in getting a resource factory that I've created myself to
reuse jndi context's to an LDAP database that is used for authentication
more.
I've created a ContextPool that handles this, and I want to retrieve
this with initCtx.lookup("java:comp/env/jndi/ContextPool");
How do I create and add the necessary resource factory? Should I modify
org.apache.naming.factroy.ResourceFactory.java ?
Any hints appreciated.
--
- Torgeir
Directory registering
Hi ! Anybody knows how to register a new directory under the TomCat ? Iam tried this in the /conf/server.xml but it doesnt work.
debugging tomcat's jndi provider
I need to look at the behaviour of the jndi provider inside tomcat. Are there any tricks to debugging tomcat? -- - Torgeir
Re: context factories
On Tue, 3 Apr 2001, Torgeir Veimo wrote:
I've read in a post by Remy with subject: "Re: ejb-ref ejb-link
Implementation in 4.0.b1",
http://w4.metronet.com/~wjm/tomcat/2001/Mar/msg00273.html that the only
two factories supported in tomcat right now is one for getting Tyrex
managed data sources User Transactions.
This message is actually out of date now. There are also default
factories to create javax.mail.Session and
javax.mail.internet.MimePartDataSource as well.
I'm interested in getting a resource factory that I've created myself to
reuse jndi context's to an LDAP database that is used for authentication
more.
I've created a ContextPool that handles this, and I want to retrieve
this with initCtx.lookup("java:comp/env/jndi/ContextPool");
How do I create and add the necessary resource factory? Should I modify
org.apache.naming.factroy.ResourceFactory.java ?
If you don't mind specifying the resource factory class yourself, you
don't need to modify any code at all -- just configure it in server.xml
like this:
Context path="/myapp" ...
...
Resource name="jndi/ContextPool"
type="com.mycompany.ContextPool"/
ResouceParams name="jndi/ContextPool"
parameter
namefactory/name
valuecom.mycompany.ContextPoolFactory/value
/parameter
parameternamename/namevaluevalue/value/parameter
...
/ResourceParams
...
/Context
where "com.mycompany.ContextPoolFactory" is a class that implements
javax.naming.spi.ObjectFactory. You can use the existing factories as
examples of how such factories can access the declared resource parameters
and use them to configure the object itself.
Any hints appreciated.
--
- Torgeir
Craig McClanahan
? on SSI virtual file
(1) According to NCSA "virtual gives a virtual path to a document on the server." So no matter which context you're in, !--#include virtual="/test.txt" -- should try to access "test.txt" on your server's root, right? Does virtual have to start with "/" always? I would think so. If not, what should be the behavior if it doesn't start with "/", context based? (2) Also, NCSA states "file gives a pathname relative to the current directory." So obviously !--#include file="test.txt" -- should try to access "test.txt" in your current directory. What about "!--#include file="/test.txt" --"? Should that look for "test.txt" on your server root or on webapp? Amy
Re: ? on SSI virtual file
Amy Roh wrote: (1) According to NCSA "virtual gives a virtual path to a document on the server." So no matter which context you're in, !--#include virtual="/test.txt" -- should try to access "test.txt" on your server's root, right? Does virtual have to start with "/" always? I would think so. If not, what should be the behavior if it doesn't start with "/", context based? snip virtual gives a virtual path to a document on the server. You must access a normal file this way, you cannot access a CGI script in this fashion. You can, however, access another parsed document. /snip I would say that !--#include virtual="/test.txt" -- tries to access test.txt in the server's root. However if you read the rfc on virtual paths you can also use ., .., dir instead of starting with a / so then the following examples would/should work: !--#include file="file.txt" -- Which is a file in the current directory. !--#include file="./file.txt" -- Which is a file in the current directory. !--#include file="dir/file.txt" -- Which is a file in the "dir" directory _above_ the current directory. !--#include file="/file.txt" -- Which is a file on the servers root. !--#include file="../file.txt" -- Which is a file in the dir _below_ the current directory. (2) Also, NCSA states "file gives a pathname relative to the current directory." So obviously !--#include file="test.txt" -- should try to access "test.txt" in your current directory. What about "!--#include file="/test.txt" --"? Should that look for "test.txt" on your server root or on webapp? snip file gives a pathname relative to the current directory. ../ cannot be used in this pathname, nor can absolute paths be used. As above, you can send other parsed documents, but you cannot send CGI scripts. /snip As i enterpret this you can _only_ access a file using the file command in the following ways: !--#include file="file.txt" -- Which is a file in the current directory. !--#include file="dir/file.txt" -- Which is a file in the "dir" directory _above_ the current directory. !--#include file="/file.txt" -- Would fail. !--#include file="../file.txt" -- Would fail. And this is how it should be implemented right now. ..bip
Re: ? on SSI virtual file
On Tue, 3 Apr 2001, Amy Roh wrote: (1) According to NCSA "virtual gives a virtual path to a document on the server." So no matter which context you're in, !--#include virtual="/test.txt" -- should try to access "test.txt" on your server's root, right? Does virtual have to start with "/" always? I would think so. If not, what should be the behavior if it doesn't start with "/", context based? If I remember this - "context based" is something specific to servlets ( 2.2 and after ), the /paths are allways relative to the server ( or vhost ) root URI. One tricky part is that /foo/bar.txt may not refer to the file ROOT/foo/bar.txt - it may be mapped by the server to a different location ( Location is similar with a servlet context - so it may be in context foo, with a different docbase ). Apache is doing a re-mapping ( run_subreq ) to get to the right file ( the relevant file is httpd-2.0/modules/filters/mod_include.c ). That mean you need to do use a request dispatcher or something equivalent to make sure the path is mapped ( and of course to play some games with the URIs to match the servlet and http server semantics ). I think the security rules are also applied during include - but you should test that. (2) Also, NCSA states "file gives a pathname relative to the current directory." So obviously !--#include file="test.txt" -- should try to access "test.txt" in your current directory. What about "!--#include file="/test.txt" --"? Should that look for "test.txt" on your server root or on webapp? Again, distant memories - but include file was supposed to be the "fast" version that doesn't do mapping/auth/etc - so it is limited to the local directory ( and I think it didn't do security checks either ). Sorry, I used SSI long ago ( I think it was a Cern server ), but I still remember some pain :-) Costin
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
amyroh 01/04/03 15:07:10 Modified:catalina/src/conf web.xml Log: Added "isVirtualWebappRelative" parameter to give an option that virtual paths can be webapp-relative. Defaults to false following NCSA. Revision ChangesPath 1.16 +5 -0 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- web.xml 2001/03/27 20:34:00 1.15 +++ web.xml 2001/04/03 22:07:10 1.16 @@ -77,6 +77,11 @@ param-namebuffered/param-name param-value1/param-value /init-param +init-param + !-- 0 == false; 1 == true -- + param-nameisVirtualWebappRelative/param-name + param-value0/param-value +/init-param load-on-startup5/load-on-startup /servlet
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi SsiMediator.java
amyroh 01/04/03 15:45:33
Modified:catalina/src/share/org/apache/catalina/util/ssi
SsiMediator.java
Log:
Fixed virtual behavior to follow NCSA rules with a webapp-relative option.
Revision ChangesPath
1.3 +48 -9
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi/SsiMediator.java
Index: SsiMediator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi/SsiMediator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SsiMediator.java 2001/04/02 21:14:29 1.2
+++ SsiMediator.java 2001/04/03 22:45:33 1.3
@@ -1,8 +1,8 @@
/*
* SsiMediator.java
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi/SsiMediator.java,v
1.2 2001/04/02 21:14:29 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2001/04/02 21:14:29 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi/SsiMediator.java,v
1.3 2001/04/03 22:45:33 amyroh Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/04/03 22:45:33 $
*
*
*
@@ -85,7 +85,8 @@
/**
* @author Bip Thelin
- * @version $Revision: 1.2 $, $Date: 2001/04/02 21:14:29 $
+ * @author Amy Roh
+ * @version $Revision: 1.3 $, $Date: 2001/04/03 22:45:33 $
*
*/
public class SsiMediator {
@@ -106,12 +107,18 @@
protected static ServletContext servletContext = null;
+protected static ServletContext origServletContext = null;
+
+protected static String contextPath = null;
+
protected static String relpath = "/";
protected static String path = new String();
protected static int debug = 0;
+protected static boolean isVirtualWebappRelative = false;
+
public SsiMediator() {}
static {
@@ -129,9 +136,10 @@
OutputStream out,
ServletContext servletContext,
int debug,
-String path) {
+String path,
+ boolean isVirtualWebappRelative) {
this.debug = debug;
- flush(req, res, out, servletContext, path);
+ flush(req, res, out, servletContext, path, isVirtualWebappRelative);
}
public final SsiCommand getCommand(String cmd) {
@@ -142,13 +150,17 @@
HttpServletResponse res,
OutputStream out,
ServletContext servletContext,
- String path) {
+ String path,
+ boolean isVirtualWebappRelative) {
this.req = req;
this.res = res;
this.out = out;
this.servletContext = servletContext;
+this.origServletContext = servletContext;
+this.contextPath = req.getContextPath();
this.path = path;
this.relpath = path.substring(0, path.lastIndexOf("/")+1);
+this.isVirtualWebappRelative = isVirtualWebappRelative;
int c=0;
serverVariables.put("AUTH_TYPE",
@@ -295,6 +307,32 @@
normalized.substring(index + 3);
}
+if (!isVirtualWebappRelative) {
+// case of virtual="file.txt", "./file.txt", or dir/file.txt
+if ((!path.startsWith("/")) || (path.startsWith("./"))) {
+// handle as file in the current directory with original servletContext
+servletContext = origServletContext;
+}else if (path.indexOf("/", 1)==-1) {
+//root context
+servletContext = servletContext.getContext("/");
+} else if (!contextPath.equals("")) {
+//starts with the context path of this webapp
+if ((normalized !=null) (normalized.startsWith(contextPath))) {
+// strip off the context path
+servletContext = servletContext.getContext(contextPath);
+normalized = normalized.substring(contextPath.length());
+}
+} else if (normalized != null){
+// find which context is the right one to handle
+String context = normalized.substring(0, path.indexOf("/", 1));
+ServletContext sc = servletContext.getContext(context);
+if (sc!=null) {
+servletContext = sc;
+normalized = normalized.substring(context.length());
+}
+}
+}
+
return (normalized);
}
@@ -325,6 +363,8 @@
* normalized = RequestUtil.URLDecode(normalized, "UTF8");
*/
+ servletContext = origServletContext;
+
if (normalized == null)
return (null);
@@ -341,8 +381,7 @@
FW: Tomcat may reveal script source code by URL trickery 2
-- From: "Sverre H. Huseby" [EMAIL PROTECTED] Reply-To: "Sverre H. Huseby" [EMAIL PROTECTED] Date: Tue, 3 Apr 2001 10:25:26 +0200 To: [EMAIL PROTECTED] Subject: Tomcat may reveal script source code by URL trickery 2 Meta comment Ok, I know there has already been a report on this problem on Bugtraq, but as I informed the Tomcat people before the CHINANSL advisory appeared here, I want to brag about it anyway. :) Also, the Tomcat'ers have provided a fix as mentioned in this advisory. == Tomcat may reveal script source code by URL trickery 2 -- Sverre H. Huseby security advisory #4, 2001-04-03 Systems affected Tomcat 4.0-b2, which includes fixes for a similar bug. Other versions before 4.0-b3 may be vulnerable too. The Tomcat team was notified on 2001-04-01, and they provided a fix on 2001-04-03. Everybody should upgrade to at least Tomcat 4.0 beta 3. Description --- Tomcat (http://jakarta.apache.org/tomcat/), the Reference Implementation for the Java Servlet 2.2 and JavaServer Pages 1.1 Technologies, may be tricked into revealing the source code of JSP scripts by using simple URL encoding. Details --- It seems that the built in web server in affected versions of Tomcat does URL decoding twice. URLs like the following http://someplace.com:8080/index.js%2570 where %25 is an URL encoded '%', and 70 is the hexadecimal value for 'p', returns the source code of index.jsp rather than running the script on the server side. To speculate (read: guess): The JSP handler is skipped as this URL does not end in ".jsp" (after URL decoding the first time), but the static file handler is nevertheless able to map the URL into a correct file name (doing URL decoding a second time). Impact -- This design error makes it possible to fetch the source code of JSP scripts. Such source code may contain database passwords and file names, and may reveal design errors or programming bugs that make it possible to further exploit the server or service. Reported by Sverre H. Huseby, [EMAIL PROTECTED] -- URL:mailto:[EMAIL PROTECTED] URL:http://shh.thathost.com/
Re: CGI support servlet (TC 4) -- feedback wanted
Right now they are basically the same scripts that I added to the examples webapp. So, should I just duplicate the scripts so we have one set in tomcat-root/webapps/examples/WEB-INF/cgi-bin and one set in tomcat-root/tester/src/bin? Or would the tester/src/bin/tester.xml simply have some targets which tested the output of some requests to http://server/examples/cgi-bin/cgitester.cgi, etc.? I think once the feature is fully implemented, we can work on a tester which tests your scripts and add it to our set of tests. So whenever the tester is ran, we can display something like "CGI tests all PASSED" following the current tester style. 5) Default location of cgi scripts In another project, we have put all cgi scripts under webapp/WEB-INF/cgi since they are then 1) not liable to be served by the container; yet 2) still encapsulated underneath the webapp's own directory structure. One observation and two issues here: Observation: the Servlet spec is obviously silent on CGI placement issues; yet we should probably support (and even default to?) something congruent with standard CGI practice of separating the HTML and CGI scripts (/doc-root and /cgi-bin) while not encouraging anything which breaks the Servlet API's web application filesystem (or war file) boundaries. Issue 1) generally, how do people like the webapp/WEB-INF/cgi solution in light of the above observation? +1 Cool. Issue 2) if people like it, should we make it the default setting (by defining an init-parameter for the CGI servlet in the container-wide web.xml file)? I think we should designate a cgi directory where people can put CGI scripts for security reasons. Yes, on a per-webapp level? I meant like an absolute directory like "cgi-bin" directory in file system. But there're options Is the source code from http://www.martindengler.com/proj/CGIGatewayServlet.zip the most updated one? I have made some more updates which I have not posted yet. Once I take into account your others' suggestions, I will update that zip file. I imagine I can make most of the changes tonight and re-package tomorrow, so hopefully a new one will be up soon. Awesome. Thanks! Cheers, Amy
[PATCH] bufferSize overflows in BodyContentImpl TC3.3M2
The bufferSize variable in BodyContentImpl is declared as an int. This
results in an integer overflow very quickly for even moderately big output.
(Think displaying the results of a SQL table as a HTML table). I imagine
that the ultimate solution will be to declare it as a long, but in the mean
time...
*** BodyContentImpl.java.orig Tue Apr 3 16:46:37 2001
--- BodyContentImpl.javaTue Apr 3 16:47:15 2001
***
*** 110,119
char[] tmp = null;
//XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
!
if (len = Constants.DEFAULT_BUFFER_SIZE) {
tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
! bufferSize = bufferSize * 2;
} else {
tmp = new char [bufferSize + len];
bufferSize += len;
--- 110,119
char[] tmp = null;
//XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
! len += Constants.DEFAULT_BUFFER_SIZE -
(len%Constants.DEFAULT_BUFFER_SIZE);
if (len = Constants.DEFAULT_BUFFER_SIZE) {
tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
! bufferSize += Constants.DEFAULT_BUFFER_SIZE;
} else {
tmp = new char [bufferSize + len];
bufferSize += len;
Re: JNDI realm for Catalina
This sounds excellent. I appreciate the ability to specify which attribute to match: I plan to use "mail" in a current application. I wonder if it wouldn't be useful to permit a principal or a credential to be an attribute in the user's (subject's) own entry, e.g., "creditbalance." (For some types of data, I wonder if it may be more efficient to maintain it "distributed" in subjects' entries rather than in a possibly very large and dynamic attribute list.) (Perhaps it's obvious, but I'll mention that I'm a bit uncertain about the distinction and appropriate practical uses of "principals" versus "credentials". ) Does this model handle "dynamic" groups, by which I mean a reference to a method/algorythm/formula computed at runtime, like "member of ou=myDepartment", or "person entries with creditbalance 1" ? I understand this can be achieved by referring to an attribute that stores a URI that includes an LDAP query string. In any case, this authenticator is a very exciting contribution. Martin John Holman wrote: One of the action items in the Catalina status document is a JNDI realm. I've been working on this recently and wonder whether what I've done would be useful to the project - though I'm not sure how best to get involved. Incidentally, the status document lists James W as a volunteer for this item. I sent James a message a few days ago asking about progress but haven't received a response yet. Anyway, this is what I've done/plan to do. The current implementation follows the general pattern of the existing JDBCRealm. It is assumed that user and role information is held in a directory server. To authenticate the user, the directory is first searched for an entry with an attribute matching the given username. An attempt is then made to bind to the directory using the name of that entry and the password. A role is represented in the directory by an entry with an attribute whose values identify the users with that role, and optionally with an attribute whose value is the name of the role. In an LDAP directory a role entry might have a uniqueMember or member attribute to hold the distinguished names of the users. However other attribute types could be used, and the values could be usernames instead of DNs. In the current implementation, all the roles associated with a user are retrieved when the user is first authenticated and then cached in the Principal object. To accommodate the different ways that user and role information can be represented in the directory a number of configuration attributes are needed - though fortunately most can have defaults. Here is a possible set: connectionURL - the connection URL to be passed to the JNDI provider. Usually this will be an LDAP URL specifying the hostname and port of the directory server and optionally the name of the root naming context. This attribute is required. Example: ldap://ldap.acme.com:389 contextFactory - the class name of the inital context factory to use. Default: com.sun.jndi.ldap.LdapCtxFactory userSearchBase - the name of the context (relative to the root context) within which to search for users. This attribute is required. Example: ou=people userNameAttribute - the name of the attribute whose value will be matched to the given username. Default: "uid" userSearchSubtree - if true the subtree starting at userSearchBase will be searched for a user with the given username. If false a one-level search is performed. Default: "false" roleSearchBase - the name of the context (relative to the root context) within which to search for roles. This attribute is required. Example: ou=groups roleMemberAttribute - the name of the attribute whose values identify the users with that role. Default: uniqueMember. roleNameAttribute - the name of the attribute whose value is the name of the role. If not specifed, a role name is constructed from the leftmost component of the name of the directory entry. (This will probably only work for LDAP-style distinguished names). roleSearchSubtree - if "true" the whole subtree starting at roleSearchBase is searched for roles. If "false" a one-level search is performed. Default: "false" roleValueIsDN - if "true" the values of the roleNameAttribute are the distinguished names of the users. If "false" they are usernames. Default: "true" [ not yet implemented - only DNs handled ] useSSL - whether to make an SSL connection to the directory server. Default: "false". [not yet implemented] connectionName - the dn to use when connecting to the directory server. If not specified an anonymous connection is used. [ not yet implemented ] connectionPassword - the password to use when connecting to the directory server. If not specified an anonymous connection is used. [ not yet implemented ] I'd welcome any feedback. John.
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util PrefixMapper.java
costin 01/04/03 21:04:50
Modified:src/share/org/apache/tomcat/util PrefixMapper.java
Log:
One bug in a previous fix, test host!=null.
Revision ChangesPath
1.10 +8 -7
jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java
Index: PrefixMapper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- PrefixMapper.java 2001/03/31 21:48:00 1.9
+++ PrefixMapper.java 2001/04/04 04:04:49 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v 1.9
2001/03/31 21:48:00 costin Exp $
- * $Revision: 1.9 $
- * $Date: 2001/03/31 21:48:00 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v 1.10
2001/04/04 04:04:49 costin Exp $
+ * $Revision: 1.10 $
+ * $Date: 2001/04/04 04:04:49 $
*
*
*
@@ -123,8 +123,8 @@
*/
public void removeAllMappings( String host, String path ) {
PrefixMapper vmap=this;
- host=host.toLowerCase();
if( host!=null ) {
+ host=host.toLowerCase();
vmap=(PrefixMapper)vhostMaps.get(host);
}
@@ -207,10 +207,11 @@
String s = path;
PrefixMapper myMap=null;
- if( host!=null )
+ if( host!=null ) {
myMap=(PrefixMapper)vhostMaps.get( host );
- if( myMap==null ) {
- myMap=(PrefixMapper)vhostMaps.get( host.toLowerCase() );
+ if( myMap==null ) {
+ myMap=(PrefixMapper)vhostMaps.get( host.toLowerCase() );
+ }
}
if( myMap==null ) myMap = this; // default server
