DO NOT REPLY [Bug 13658] - javax.servlet.request.key_size attribute isn't being set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13658. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13658 javax.servlet.request.key_size attribute isn't being set --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 06:32 --- It all works for me (against CVS HEAD) using JSSE 1.0.2 with JVM 1.3.1. I'm leaving the bug open assuming that you are using JSSE 1.1.x that comes with the 1.4.x JVM. If you could confirm this, it would be a big help. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11891] - JspC does not work for webapps
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11891. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11891 JspC does not work for webapps --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 07:58 --- Mark, that patch introduced other problems with normal JSP compilation, so I have backed it out of my copy of jasper.Note that I'm not a tomcat committer and this issue has yet to be assigned to a tomcat developer - so I don't know if it is being worked on? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL client auth in Tomcat 4.0
Clere, Jean-Frederic wrote: Steven Bradley wrote: I'm using Tomcat 4.0 standalone on Windows 2000 and am having trouble getting SSL client authentication working (getting SSL server auth working was a snap). Here's what I've done so far: * created a self-signed client cert using openSSL (key usage includes digital signature) * imported client cert (and private key) into Internet Explorer (by way of a PKCS#12 file) * imported the Tomcat JKS file with the client certificate CA file? * configure tomcat server.xml file as follows: Connector className=org.apache.catalina.connector.http.HttpConnector port=443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0 scheme=https secure=true Factory className=org.apache.catalina.net.SSLServerSocketFactory clientAuth=true keystoreFile=conf/server.keystore keystorePass=password protocol=TLS/ /Connector * stop/start tomcat * point IE browser to https://localhost/index.html What IE tells me is that the page can't be displayed (after some handshaking attempts). Unfortunately, there is no log info generated (even if I increase the debug param in the Connector element). Try with Mozilla or with openssl (something like: openssl s_client -port 8443 -host localhost). Does it work when clientAuth=false? Any clues as to what I may be doing wrong? Has ANYONE been able to get SSL client authentication working with Tomcat 4.0 standalone (Catalina). Sure I tested it... It worked ok. I have found a document that I wrote at that time: +++ Steps to set up a demoCA and user certificates: 1 - /usr/local/ssl/misc/CA.pl -newca This creates a demoCA directory that contains the CA certificates. 2 - /usr/local/ssl/misc/CA.pl -newreq This creates a newreq.pem that contains the private key and request. 3 - separe the request and private key. Put the private key is key.pem and the request in newreq.pem 4 - /usr/local/ssl/misc/CA.pl -signreq It displays the certificate before signing it. The result is in newcert.pem 5 - /usr/local/ssl/bin/openssl pkcs12 -export -inkey key.pem \ -in newcert.pem -out test.p12 The test.p12 contains a file that can be imported in the browser. 6 - import in the browser the test.p12 file. 7 - Add the CA cert in the $JAVA_HOME/jre/lib/security/cacerts chmod u+w $JAVA_HOME/jre/lib/security/cacerts $JAVA_HOME/keytool -import -trustcacerts -file demoCA/cacert.pem \ -keystore $JAVA_HOME/jre/lib/security/cacerts +++ Make sure the CA that has signed your certificates is in the CA file ($JAVA_HOME/jre/lib/security/cacerts or something). Thanks in advance -- Steven -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13285] - admin web application fail with virtual host
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13285. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13285 admin web application fail with virtual host --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 09:19 --- Created an attachment (id=3483) new admin web wich manage virtuals hosts -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13285] - admin web application fail with virtual host
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13285. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13285 admin web application fail with virtual host [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 09:31 --- With the new attachment, the problem is resolved. This attachment is the version of admin.war of 14 October 2002 with management for virtuals Hosts. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
linux tomcat usage
Sir, I am programmer in java Servlets. Still date i am using tomcat server for windows os. Now recently i switched to linux OS. I had downloaded the linux version of jakarta-tomcat. But i couldn't able to install it. I would be happy if you specify or send me the documents of how to install tomcat on linux os. Thanking you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13533] - JSPs compiled inconsistently
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13533. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13533 JSPs compiled inconsistently --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 09:46 --- The main problem we are having is that when you first deploy the war and then try to access the pages we get the following: 'An error occurred at line: -1 in the jsp file: null' This problem occurs whether we run the app with the WARP connector or start tomcat standalone and use the HTTP 1.1 connector. It is really strange because if you refresh the page then everything works ok from that point on. This only happens when we try to access the app after we have deployed a new WAR. If you stop and start tomcat/apache after this then everything works ok. Is there a possibility this could be caused by a corrupted OS? The server has recently been upgraded from Linux 4.0 to 4.2 and could have been installed incorrectly, we will hopefully be able to reinstall the OS this week. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: linux tomcat usage
kannaiyan balakrishnan wrote: Sir, I am programmer in java Servlets. Still date i am using tomcat server for windows os. Now recently i switched to linux OS. I had downloaded the linux version of jakarta-tomcat. But i couldn't able to install it. I would be happy if you specify or send me the documents of how to install tomcat on linux os. That a user list question. And it depends on what you have downloaded. I guess a tar.gz files. you have to extract the file contents: tar xvfz jakarta-tomcat-4.1.12.tar.gz that creates a jakarta-tomcat-4.1.12 directory. Ajust JAVA_HOME to running JDK change directory to jakarta-tomcat-4.1.12 and do bin/catalina.sh start. Something like +++ export JAVA_HOME=/home/jakarta/j2sdk1.4.1 (cd jakarta-tomcat-4.1.12 bin/catalina.sh start ) Thanking you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13677] - Deployment Problem in Tomcat4.1.12
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13677. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13677 Deployment Problem in Tomcat4.1.12 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 10:54 --- The Context element values looks incorrect (esp the docBase attribute value, which should be relative to the Host appBase - ie, try ERDS-app). In the next release, this will not cause Tomcat to crash on startup (ie, it will run, but without the offending webapp). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf web.xml
remm2002/10/16 04:44:16 Modified:catalina/src/conf web.xml Log: - Disable invoker servlet by default. Revision ChangesPath 1.5 +2 -0 jakarta-tomcat-catalina/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/web.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- web.xml 12 Sep 2002 07:02:16 - 1.4 +++ web.xml 16 Oct 2002 11:44:16 - 1.5 @@ -262,10 +262,12 @@ /servlet-mapping !-- The mapping for the invoker servlet -- +!-- servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping +-- !-- The mapping for the JSP servlet -- servlet-mapping -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jsp:plugin and EMBED tags (Someone please apply this fix)
As referred in bug 12794, there is a problem with the jsp:plugin
generating
a bad parameter list in EMBED tags.
I wish to propose this fix:
In jasper/src/share/org/apache/jasper/compiler/Generator.java
At line 891 of version 1.35.2.8 (In 4.1.12)
Where it is:
String s0 = makeAttr(name, name) + value= +
attributeValue(n.getValue(), false);
if (ie) {
s0 = PARAM + s0 + '';
}
It should be:
String s0=null;
if(ie) {
s0=PARAM+makeAttr(name, name)+ value=+
attributeValue(n.getValue(), false)+;
} else {
s0= +name+=+attributeValue(n.getValue(), false);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13689] New: - Classloader paths for 'Common' classes and libraries are inappropriate
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13689. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13689 Classloader paths for 'Common' classes and libraries are inappropriate Summary: Classloader paths for 'Common' classes and libraries are inappropriate Product: Tomcat 4 Version: 4.0.6 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Currently 'Common' classes and libraries are searched from $CATALINA_HOME, where they should better be located in $CATALINA_BASE. At the very least, $CATALINA_BASE/common/lib and $CATALINA_BASE/common/classes should be supplementary. Consider a shared hosting environment where the Tomcat core classes are kept read-only by a super-user, and entities run (many) instances of Tomcat from their own $CATALINA_BASE directories. Putting common jars in $CATALINA_HOME/common/lib isn't an option if two entities are using incompatible versions of the same library. Appending $CATALINA_BASE/common/lib and classes should break very, very few existing installations. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13690] New: - jndi connection pool fails with postgresql database
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13690. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13690 jndi connection pool fails with postgresql database Summary: jndi connection pool fails with postgresql database Product: Tomcat 4 Version: 4.1.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, i get the follwoing exception when trying to connect to a postgresql database using tomcat 4.12 and the postgresql jdbc driver : jdbc7.0.1.2.jar. Is this a problem with tomcat or with the postgresql database / jdbc driver ?? org.apache.commons.dbcp.DbcpException: Something unusual has occured to cause the driver to fail. Please report this exception: java.sql.SQLException: No pg_hba.conf entry for host 192.168.156.33, user soloweb, database soloweb at org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:85) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:184) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(Unknown Source) at org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:117) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:110) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:312) at de.soloplan.util.database.JNDIConnectionPool.getConnection(JNDIConnectionPool.java:114) at de.soloplan.util.database.JNDIConnectionPool.getState(JNDIConnectionPool.java:171) at de.soloplan.util.database.ShowDBStatusServlet.doGet(ShowDBStatusServlet.java:49) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:527) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380) at
DO NOT REPLY [Bug 13689] - Classloader paths for 'Common' classes and libraries are inappropriate
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13689. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13689 Classloader paths for 'Common' classes and libraries are inappropriate [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 13:09 --- common is considered to be the server binary, the same way server is. You have the lib and classes folder for what you want to do. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13690] - jndi connection pool fails with postgresql database
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13690. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13690 jndi connection pool fails with postgresql database [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 13:11 --- This should be reported as a possible bug of the commons-dbcp component, which Tomcat uses. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Netbeans 3.4 with builtin Tomcat 4.0.1(problem with pathinfo)
Hello, I am having problems with the Tomcat server in Netbeans that i run for the local testing. The problem is as follows. I have a servlet which i cannot get to work with extra path info. When i call it with http://localhost/servlet/my.servlet?param=1 it starts up the correct servlet and everything seems fine. However when i try to add the pathinfo to it as in http://localhost/servlet/my.servlet/some/path?param=1 it fails telling me that the requested resource (/servlet/my.servlet/some/path) is not available. Hope that someone can enlighten me on this problem as this is something i cannot resolve. Regards, Ulrik Sannsell -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13692] New: - request.getCharacterEncoding() is NULL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13692. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13692 request.getCharacterEncoding() is NULL Summary: request.getCharacterEncoding() is NULL Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am a multi-charset user. I used Resin to be my JSP-container befor. After I try to use Tomcat to instead of Resin, it's bother with me that Tomcat can not transfer the charset to the type that I assigned. So I try to figure out what happened. In Tomcat 4.1.12, I try to modify this file org.apache.jasper.compiler.Generator.java. In line 460-470 , I try to print the request.getCharacterEncoding(). Like these code, out.printin(response.setContentType(); out.print (quote(pageInfo.getContentType())); out.println();); // modify by Simon Chung 10/16/2002 // [EMAIL PROTECTED] // fix request.getCharacterEncoding() is equal to 'null'. // request.setCharacterEncoding(response.getCharacterEncoding()); out.printil(System.out.println(request.getCharacterEncoding());); out.printil(request.setCharacterEncoding(response.getCharacterEncoding());); out.printil(System.out.println(request.getCharacterEncoding());); // end of modify out.printil(pageContext = _jspxFactory.getPageContext(this, request, response,); And find that the first System.out is null. And the second System.out is the type that I assigned. OK. Got it! The 'request' and 'response' charset-encoding are not same. So I try to fix my jasper-compiler.jar. And it works very good. Then I reponse this bug to you now. Please give me a notice what you want to do. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] CoyoteRequest.doGetSession
The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. -1 for changing/removing the doPrivileged() Regards, Glenn Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented somewhere since Manager written for Tomcat 4 may no longer works. The catalina.policy file can then be used to give special privileges to ManagerX, but not to ManagerY (same for Store instance or whatever objects is used), based on codebase. Any recommendations/objections to the modification? Thanks, -- Jeanfrancois P.S Right now, if you run Tomcat with the default Security manager, the doPrivilege block is useless. For performance reason, we should avoid this call. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10891] - mod_jk2 addcookie setheader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10891. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10891 mod_jk2 addcookie setheader --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 14:43 --- This bug also manifests in Tomcat 4.1.12, Apache 2.0.43, on Linux. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13673] - Exception in StandardSession when writing a session manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13673. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13673 Exception in StandardSession when writing a session manager [EMAIL PROTECTED] changed: What|Removed |Added Summary|Problem in StandardSession |Exception in StandardSession |when writing a session |when writing a session |manager |manager -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] CoyoteRequest.doGetSession
Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented somewhere since Manager written for Tomcat 4 may no longer works. The catalina.policy file can then be used to give special privileges to ManagerX, but not to ManagerY (same for Store instance or whatever objects is used), based on codebase. Any recommendations/objections to the modification? Thanks, -- Jeanfrancois P.S Right now, if you run Tomcat with the default Security manager, the doPrivilege block is useless. For performance reason, we should avoid this call. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12699] - Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699 Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1 --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:16 --- I have found the same problem, using Apache 2.0.43, Tomcat 4.1.12, and JK2 on Linux. mod_webapp does not exhibit this behavior (although I have different problems getting it to work). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12699] - Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699 Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1 --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:25 --- Could you try with JK (1.2.0) and told us if it still don't works ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12699] - Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12699 Only one cookie sent back to Apache2 with mod_jk2 and Tomcat4.1 --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 15:26 --- Hum, I means Apache 2.0.43, Tomcat 4.1.12, and JK (1.2.0) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Newbie] Need some help
I currently have PHP running on my Linux learning server along with Apache. Though I have been programming for a living since 1973, my knowledge of Java, how serverside Java works, how to implement JSP is nil. Is there some documentation that can get me started without overloading me with a plethora if details? I would like to install TomCat on my RH Linux server, but the Install docs are rather daunting.. Todd -- Ariste Software, Petaluma, CA 94952
Re: [Newbie] Need some help
Todd Cary wrote: I currently have PHP running on my Linux learning server along with Apache. Though I have been programming for a living since 1973, my knowledge of Java, how serverside Java works, how to implement JSP is nil. Is there some documentation that can get me started without overloading me with a plethora if details? I would like to install TomCat on my RH Linux server, but the Install docs are rather daunting.. You should go to tomcat-user list and since you're using RH Linux, take a look at the rpm available at : http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/rpms/ Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java ApplicationFilterConfig.java ApplicationFilterChain.java
jfarcand2002/10/16 08:42:09 Modified:catalina/src/share/org/apache/catalina/core StandardWrapper.java ApplicationFilterConfig.java ApplicationFilterChain.java Log: Security Audit. Change the SecurityUtil package dir. Revision ChangesPath 1.6 +5 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java Index: StandardWrapper.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- StandardWrapper.java 9 Oct 2002 08:01:11 - 1.5 +++ StandardWrapper.java 16 Oct 2002 15:42:09 - 1.6 @@ -96,7 +96,7 @@ import org.apache.catalina.loader.StandardClassLoader; import org.apache.catalina.util.Enumerator; import org.apache.catalina.util.InstanceSupport; -import org.apache.catalina.util.SecurityUtil; +import org.apache.catalina.security.SecurityUtil; import org.apache.tomcat.util.log.SystemLogHandler; import java.security.PrivilegedActionException; 1.3 +5 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java Index: ApplicationFilterConfig.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterConfig.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ApplicationFilterConfig.java 13 Sep 2002 21:59:48 - 1.2 +++ ApplicationFilterConfig.java 16 Oct 2002 15:42:09 - 1.3 @@ -76,7 +76,7 @@ import org.apache.catalina.Context; import org.apache.catalina.deploy.FilterDef; import org.apache.catalina.util.Enumerator; -import org.apache.catalina.util.SecurityUtil; +import org.apache.catalina.security.SecurityUtil; /** * Implementation of a codejavax.servlet.FilterConfig/code useful in 1.3 +5 -5 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java Index: ApplicationFilterChain.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ApplicationFilterChain.java 13 Sep 2002 21:59:48 - 1.2 +++ ApplicationFilterChain.java 16 Oct 2002 15:42:09 - 1.3 @@ -83,7 +83,7 @@ import org.apache.catalina.InstanceEvent; import org.apache.catalina.util.InstanceSupport; import org.apache.catalina.util.StringManager; -import org.apache.catalina.util.SecurityUtil; +import org.apache.catalina.security.SecurityUtil; /** * Implementation of codejavax.servlet.FilterChain/code used to manage -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Newbie] Need some help
Henri Gomez wrote: Todd Cary wrote: I currently have PHP running on my Linux learning server along with Apache. Though I have been programming for a living since 1973, my knowledge of Java, how serverside Java works, how to implement JSP is nil. Is there some documentation that can get me started without overloading me with a plethora if details? I would like to install TomCat on my RH Linux server, but the Install docs are rather daunting.. You should go to tomcat-user list I mean, tomcat-user list which be able to provide much more users informations and experience than tomcat-dev which is focused on tomcat developpement. Regards ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util SecurityUtil.java
jfarcand2002/10/16 08:43:30 Removed: catalina/src/share/org/apache/catalina/util SecurityUtil.java Log: Move the class to the security package. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 5.0: primary development platform
What's the primary platform used for development of Tomcat 5.0 (or 4.1.x)? Having some issues getting things like the Channel Unix socket to work on Solaris and want to get involved if this is something that isn't being looked at because it's not an available platform to develop/test on. Comments, suggestions welcome, anyone? Paul -- mailto:[EMAIL PROTECTED] Enterprise Distributed Capabilities EDS Corporation 248-265-8283 Paul J. Brzezinski ([EMAIL PROTECTED]).vcf Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader StandardClassLoader.java WebappClassLoader.java WebappLoader.java
jfarcand2002/10/16 09:08:29
Modified:catalina/src/share/org/apache/catalina/loader
StandardClassLoader.java WebappClassLoader.java
WebappLoader.java
Log:
Security Audit. Protect the findRepositories public method by cloning the String[]
values. This method is no used right now. Should I remove it instead of protecting it?
Revision ChangesPath
1.5 +7 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
Index: StandardClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- StandardClassLoader.java 11 Oct 2002 16:08:59 - 1.4
+++ StandardClassLoader.java 16 Oct 2002 16:08:28 - 1.5
@@ -429,11 +429,12 @@
/**
* Return a String array of the current repositories for this class
* loader. If there are no repositories, a zero-length array is
- * returned.
+ * returned. For security reason, returns a clone of the Array (since
+ * String are immutable).
*/
public String[] findRepositories() {
-return (repositories);
+return ((String[])repositories.clone());
}
1.10 +7 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- WebappClassLoader.java11 Oct 2002 15:52:01 - 1.9
+++ WebappClassLoader.java16 Oct 2002 16:08:29 - 1.10
@@ -668,11 +668,12 @@
/**
* Return a String array of the current repositories for this class
* loader. If there are no repositories, a zero-length array is
- * returned.
+ * returned.For security reason, returns a clone of the Array (since
+ * String are immutable).
*/
public String[] findRepositories() {
-return (repositories);
+return ((String[])repositories.clone());
}
1.5 +7 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
Index: WebappLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- WebappLoader.java 20 Sep 2002 21:22:31 - 1.4
+++ WebappLoader.java 16 Oct 2002 16:08:29 - 1.5
@@ -536,10 +536,12 @@
/**
* Return the set of repositories defined for this class loader.
* If none are defined, a zero-length array is returned.
+ * For security reason, returns a clone of the Array (since
+ * String are immutable).
*/
public String[] findRepositories() {
-return (repositories);
+return ((String[])repositories.clone());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13658] - javax.servlet.request.key_size attribute isn't being set
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13658. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13658 javax.servlet.request.key_size attribute isn't being set --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 16:25 --- I'm using J2SE 1.4.1 and the version of JSSE that comes with it standard. I'm running it on a Solaris 8 system with a recent patch cluster installed and I'm using Tomcat 4.1.12. I would be happy to test it with a nightly build if you have a binary for it. I can't seem to locate the nightly builds on the Web site. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13700] New: - XML parser goes Internet when parsing a TLD
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13700. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13700 XML parser goes Internet when parsing a TLD Summary: XML parser goes Internet when parsing a TLD Product: Tomcat 4 Version: 4.1.10 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When Tomcat parses a tag library descriptor the XML parser (or at least Crimson in my case) seems to try to load the DTD specified by the system identifier in the DOCTYPE statement. The latter looks like this: !DOCTYPE taglib PUBLIC -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd; Here the system identifier is http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd and Crimson tries to fetch the DTD via the Internet. This a) is unnecessary since the web container should already know about certain DTDs and b) is not possible if the web container isn't connected to the Internet). For me that means that I cannot run my web application under Tomcat in a network that is separated from the Internet. The exception I get is the following: javax.servlet.ServletException: Exception processing TLD META-INF/misc.tld in JAR at resource path /WEB-INF/lib/misc-taglib.jar at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:934) at org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3493) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:257) at org.apache.catalina.core.StandardHost.install(StandardHost.java:772) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:569) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:411) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:879) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:368) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2191) at org.apache.catalina.startup.Catalina.start(Catalina.java:510) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) - Root Cause - java.net.ConnectException: Connection timed out at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3182) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:2870) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1167) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:489) at org.apache.crimson.parser.Parser2.parse(Parser2.java:305) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:442) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.startup.ContextConfig.tldScanStream(ContextConfig.java:977) at org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:921) at
DO NOT REPLY [Bug 12794] - jsp:plugin produces unuseable embed tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12794. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12794 jsp:plugin produces unuseable embed tag [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 16:58 --- *** This bug has been marked as a duplicate of 13536 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13536] - Erroneous code generated for jsp:param when request-time attribute value is used
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13536. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13536 Erroneous code generated for jsp:param when request-time attribute value is used [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 16:58 --- *** Bug 12794 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13689] - Classloader paths for 'Common' classes and libraries are inappropriate
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13689. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13689 Classloader paths for 'Common' classes and libraries are inappropriate [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-10-16 17:07 --- Very well, the 'shared' category, then... ...but both lib and classes are resolved relative to CATALINA_HOME, where they should more properly resolved to CATALINA_BASE. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 5.0: primary development platform
Brzezinski, Paul J wrote: What's the primary platform used for development of Tomcat 5.0 (or 4.1.x)? I don't think there is any 'primary platform'. Having some issues getting things like the Channel Unix socket to work on Solaris and want to get involved if this is something that isn't being looked at because it's not an available platform to develop/test on. Comments, suggestions welcome, anyone? If you have issues - and would like to solve them, then many thanks and you're welcome :-) That's how things work best. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] CoyoteRequest.doGetSession
I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. I also thing that the permissions should be granted on apps, not managers. The manager should check and have control over the operation that it's doing. ( for example give only some applications permissions to serialize the session in a file - that's probably a bad example as using security manager for that is not the best implementation, but I think you get my point ). Costin Jean-Francois Arcand wrote: Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented somewhere since Manager written for Tomcat 4 may no longer works. The catalina.policy file can then be used to give special privileges to ManagerX, but not to ManagerY (same for Store instance or whatever objects is used), based on codebase. Any recommendations/objections to the modification? Thanks, -- Jeanfrancois P.S Right now, if you run Tomcat with the default Security manager, the doPrivilege block is useless. For performance reason, we should avoid this call. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java
luehe 2002/10/16 10:19:19
Modified:jasper2/src/share/org/apache/jasper/compiler
TagLibraryInfoImpl.java
Log:
Fixed Bugtraq 4763825: TagAttributeInfo.getTypeName returns null for a
static attribute.
Revision ChangesPath
1.18 +10 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- TagLibraryInfoImpl.java 12 Oct 2002 18:55:29 - 1.17
+++ TagLibraryInfoImpl.java 16 Oct 2002 17:19:19 - 1.18
@@ -466,9 +466,9 @@
TagAttributeInfo createAttribute(TreeNode elem) {
String name = null;
+String type = null;
boolean required = false, rtexprvalue = false, reqTime = false,
isFragment = false;
-String type = null;
Iterator list = elem.findChildren();
while (list.hasNext()) {
@@ -502,6 +502,12 @@
}
}
+ if (!rtexprvalue) {
+ // According to JSP spec, for static values (those determined at
+ // translation time) the type is fixed at java.lang.String.
+ type = java.lang.String;
+ }
+
return new TagAttributeInfo(name, required, type, rtexprvalue,
isFragment);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] CoyoteRequest.doGetSession
Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. I also thing that the permissions should be granted on apps, not managers. The manager should check and have control over the operation that it's doing. ( for example give only some applications permissions to serialize the session in a file - that's probably a bad example as using security manager for that is not the best implementation, but I think you get my point ). Persisting session data is the responsibility of the container not the web application. Session management/persistence should be completely transparent to the webapp including security policy permissions required for managing/persisting those sessions. Costin Jean-Francois Arcand wrote: Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented
Re: [Security Audit] CoyoteRequest.doGetSession
Glenn Nielsen wrote: Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. Eum...why waiting for a security issue (joke: we are not Microsoft ;-) ). Spending time trying to demonstrate a security hole will take as much time as reducing the doPrivilege block. I understand your point but still, I consider the doPrivilege block too large. And still, when Tomcat is used as it is (with the default SecurityManager), the doPrivilege block is *not* required. For a lot of Tomcat users, we are forcing a doPrivilege block. Correct me if I'm wrong, but only JDBCStore and FileStore needs to be changed. I volonteer to make the extra work. -- Jeanfrancois I also thing that the permissions should be granted on apps, not managers. The manager should check and have control over the operation that it's doing. ( for example give only some applications permissions to serialize the session in a file - that's probably a bad example as using security manager for that is not the best implementation, but I think you get my point ). Persisting session data is the responsibility of the container not the web application. Session management/persistence should be completely transparent to the webapp including security policy permissions required for managing/persisting those sessions. Costin Jean-Francois Arcand wrote: Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required)
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityConfig.java
jfarcand2002/10/16 13:05:29
Added: catalina/src/share/org/apache/catalina/security
SecurityConfig.java
Log:
Refactorize Catalina.java and CatalinaService.java. Merge the security code into a
single class.
Revision ChangesPath
1.1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityConfig.java
Index: SecurityConfig.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Tomcat, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.catalina.security;
import java.security.Security;
/**
* Util class to protect Catalina against package access and insertion.
* The code are been moved from Catalina.java
* @author the Catalina.java authors
* @author Jean-Francois Arcand
*/
public final class SecurityConfig{
private static SecurityConfig singleton = null;
private final static String PACKAGE_ACCESS = org.apache.catalina.
+ ,org.apache.jasper.
+ ,org.apache.coyote.
+ ,org.apache.tomcat.;
private final static String PACKAGE_DEFINITION= java.,
+ PACKAGE_ACCESS;
/**
* Create a single instance of this class.
*/
private SecurityConfig(){
}
/**
* Retuens the singleton instance of that class.
* @return an instance of that class.
*/
public static SecurityConfig newInstance(){
if (singleton == null){
singleton = new SecurityConfig();
}
return singleton;
}
/**
* Set the security package.access value.
*/
public void setPackageAccess(){
setSecurityProperty(package.access, PACKAGE_ACCESS);
}
/**
* Set the security package.definition value.
*/
public void setPackageDefinition(){
setSecurityProperty(package.definition, PACKAGE_DEFINITION);
}
/**
* Set the
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Catalina.java CatalinaService.java
jfarcand2002/10/16 13:10:01
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
CatalinaService.java
Log:
Refactoring Catalina.java and CatalinaService.java. Merge the code into one class:
o.a.c.security.SecurityConfig.
Revision ChangesPath
1.7 +9 -28
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Catalina.java 15 Oct 2002 20:44:45 - 1.6
+++ Catalina.java 16 Oct 2002 20:10:01 - 1.7
@@ -69,10 +69,7 @@
import java.io.FileInputStream;
import java.io.IOException;
import java.io.OutputStream;
-import java.lang.reflect.InvocationTargetException;
-import java.lang.reflect.Constructor;
import java.net.Socket;
-import java.security.Security;
import java.util.Stack;
import org.apache.catalina.Container;
import org.apache.catalina.Lifecycle;
@@ -80,6 +77,7 @@
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Server;
import org.apache.catalina.Loader;
+import org.apache.catalina.security.SecurityConfig;
import org.apache.commons.digester.Digester;
import org.apache.commons.digester.Rule;
import org.apache.tomcat.util.log.SystemLogHandler;
@@ -479,27 +477,10 @@
}
}
-// If a SecurityManager is being used, set properties for
-// checkPackageAccess() and checkPackageDefinition
-if( System.getSecurityManager() != null ) {
-String access = Security.getProperty(package.access);
-if( access != null access.length() 0 )
-access += ,;
-else
-access = sun.,;
-Security.setProperty(package.access,
-access +
org.apache.catalina.,org.apache.jasper.,org.apache.coyote., org.apache.tomcat.);
-String definition = Security.getProperty(package.definition);
-if( definition != null definition.length() 0 )
-definition += ,;
-else
-definition = sun.,;
-Security.setProperty(package.definition,
-// FIX ME package javax. was removed to prevent HotSpot
-// fatal internal errors
-definition +
java.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,
org.apache.tomcat.);
-}
-
+SecurityConfig securityConfig = SecurityConfig.newInstance();
+securityConfig.setPackageDefinition();
+securityConfig.setPackageAccess();
+
// Replace System.out and System.err with a custom PrintStream
SystemLogHandler systemlog = new SystemLogHandler(System.out);
System.setOut(systemlog);
1.6 +8 -28
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java
Index: CatalinaService.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- CatalinaService.java 15 Oct 2002 20:44:45 - 1.5
+++ CatalinaService.java 16 Oct 2002 20:10:01 - 1.6
@@ -68,10 +68,6 @@
import java.io.File;
import java.io.IOException;
import java.io.OutputStream;
-import java.lang.reflect.InvocationTargetException;
-import java.lang.reflect.Constructor;
-import java.net.Socket;
-import java.security.Security;
import java.util.Stack;
import org.apache.catalina.Container;
import org.apache.catalina.Lifecycle;
@@ -79,6 +75,7 @@
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Server;
import org.apache.catalina.Loader;
+import org.apache.catalina.security.SecurityConfig;
import org.apache.commons.digester.Digester;
//import org.apache.tomcat.util.IntrospectionUtils;
@@ -264,26 +261,9 @@
org.apache.naming.java.javaURLContextFactory);
}
-// If a SecurityManager is being used, set properties for
-// checkPackageAccess() and checkPackageDefinition
-if( System.getSecurityManager() != null ) {
-String access = Security.getProperty(package.access);
-if( access != null access.length() 0 )
-access += ,;
-else
-access = sun.,;
-Security.setProperty(package.access,
-access +
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler PageDataImpl.java
luehe 2002/10/16 13:15:32
Modified:jasper2/src/share/org/apache/jasper/compiler
PageDataImpl.java
Log:
Removed outdated comments
Revision ChangesPath
1.7 +3 -7
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java
Index: PageDataImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- PageDataImpl.java 1 Aug 2002 21:17:58 - 1.6
+++ PageDataImpl.java 16 Oct 2002 20:15:32 - 1.7
@@ -279,17 +279,14 @@
}
public void visit(Node.Declaration n) throws JasperException {
- // jsp:declaration has no attributes, except for jsp:id
appendTag(JSP_DECLARATION, n.getAttributes(), n.getText());
}
public void visit(Node.Expression n) throws JasperException {
- // jsp:scriptlet has no attributes, except for jsp:id
appendTag(JSP_EXPRESSION, n.getAttributes(), n.getText());
}
public void visit(Node.Scriptlet n) throws JasperException {
- // jsp:scriptlet has no attributes, except for jsp:id
appendTag(JSP_SCRIPTLET, n.getAttributes(), n.getText());
}
@@ -346,7 +343,6 @@
}
public void visit(Node.JspText n) throws JasperException {
- // jsp:text has no attributes, except for jsp:id
appendTag(JSP_TEXT, n.getAttributes(), n.getBody());
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Proposal] Having a Tomcat.security file.
Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Actually, the list of package access/definition are harcoded in that class. I would like to propose we move this package list into a Tomcat.security file following the J2SE format (see below). This way if people needs accesses to a package, they will have the opportunity to do it with having to recompile Catalina. Righ now, some Watchdog tests are failling because they need accesses to o.a.t.util, and yesterday, we have started protecting this package. What do you think? I know, that's another config file (I don't like having another file). I don't see where we could place that information. Thanks, -- Jeanfrancois # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageAccess unless the # corresponding RuntimePermission (accessClassInPackage.+package) has # been granted. package.access=sun. # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageDefinition unless the # corresponding RuntimePermission (defineClassInPackage.+package) has # been granted. # # by default, no packages are restricted for definition, and none of # the class loaders supplied with the JDK call checkPackageDefinition. # #package.definition= -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
security
Looking into the Tomcat jars, I noticed the package org.apache.jk
isn't blocked... so even with the Security Manager running, I think I am
able to get catalina to load arbitrary classes like this,
%
org.apache.jk.apr.TomcatStarter.mainClasses = new String[]{
someClass };
org.apache.jk.apr.TomcatStarter.main(new String[0]);
%
So, My question is, should we block access to package org.apache.jk
from webapps?
Cheers,
-bob
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Having a Tomcat.security file.
Jean-Francois Arcand wrote: Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Works for me! You might consider moving o.a.c.startup.SecurityClassLoad.java into o.a.c.security also since it is directly related to use of the SecurityManager. Is this change just in Tomcat 5? Actually, the list of package access/definition are harcoded in that class. I would like to propose we move this package list into a Tomcat.security file following the J2SE format (see below). This way if people needs accesses to a package, they will have the opportunity to do it with having to recompile Catalina. If someone needs access to a restricted package they can grant the appropriate RuntimePermission in their catalina.policy. What packages need restrictions rarely change. Moving the list of packages into a Global variable would make it easier to change these the rare times we need to. But I am -1 for adding a new config file just for this. If somone has their own packages which they feel need restrictions they can always update their own $JAVA_HOME/jre/lib/security/java.security file. Righ now, some Watchdog tests are failling because they need accesses to o.a.t.util, and yesterday, we have started protecting this package. Either grant the appropriate permissions where needed in catalina.policy or wrap more code with doPrivileged() in catalina methods which need it. There are classes or sub packages in org.apache.tomcat.* which need to be restricted. But are the classes which are causing the failure ones which are sensitive from a security standpoint. If not, perhaps those classes should be moved into a different package which is not restricted. If this isn't workable then either grant the appropriate permissions where needed in catalina.policy or wrap more code with doPrivileged() in catalina methods which need it. SecurityManager related changes and subsequent testing with the default policy file and a very strict policy file can be a very painstaking process. I am happy to more developers getting involved in this area of Tomcat. :-) Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Having a Tomcat.security file.
+1 on the proposal. However I'm not sure about the change on o.a.t.util, and neither the other jk packages. I do agree the package should be sealed to protect package fields and methods. But I don't think it should be restricted - or at least it should be possible for webapps to include the package in WEB-INF/lib and use it as a library. ( i.e. package.access should be true for it ). Costin Jean-Francois Arcand wrote: Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Actually, the list of package access/definition are harcoded in that class. I would like to propose we move this package list into a Tomcat.security file following the J2SE format (see below). This way if people needs accesses to a package, they will have the opportunity to do it with having to recompile Catalina. Righ now, some Watchdog tests are failling because they need accesses to o.a.t.util, and yesterday, we have started protecting this package. What do you think? I know, that's another config file (I don't like having another file). I don't see where we could place that information. Thanks, -- Jeanfrancois # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageAccess unless the # corresponding RuntimePermission (accessClassInPackage.+package) has # been granted. package.access=sun. # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageDefinition unless the # corresponding RuntimePermission (defineClassInPackage.+package) has # been granted. # # by default, no packages are restricted for definition, and none of # the class loaders supplied with the JDK call checkPackageDefinition. # #package.definition= -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: security
On Wed, 2002-10-16 at 17:12, Costin Manolache wrote:
Bob Herrmann wrote:
Looking into the Tomcat jars, I noticed the package org.apache.jk
isn't blocked... so even with the Security Manager running, I think I am
able to get catalina to load arbitrary classes like this,
%
org.apache.jk.apr.TomcatStarter.mainClasses = new String[]{
someClass };
org.apache.jk.apr.TomcatStarter.main(new String[0]);
%
So, My question is, should we block access to package org.apache.jk
from webapps?
Bob,
This won't change the security rules or context in any way. If you
are able to create 'someClass', you can call it directly. If
you call it via TomcatStarter - there is no difference as long
as no doPriviledged block is reached ( since the security context
is the intersection of all callers - and this call is originated
from user code ).
I am a tad fuzzy on this security stuff... but if the system class
loader is (or a higher privileged class loader has loaded the
TomcatStarter class), then wont the Class.forName() that it does
bypass the possible webapp restriction on class loading... (for example
the webapp classloader restricts accessing org.apache.catalina.*)
I also think jk is loaded in the server loader - so it shouldn't be
visible.
My jsp page compiles and seems to invoke the TomcatStarter
Please, lets wait few more days for commiter list creation and use it
for this kind of discussions. If this would be a real exploit, it would be
much better to have the information public _after_ a fix is commited.
ok.
Cheers,
-bob
We can forward all the mails to tomcat-dev with a small delay and
nothing will be lost. If a problem is real, we can fix it first
and then bounce the message. If not - we can just bounce them
after we find it is harmless.
--
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Having a Tomcat.security file.
Glenn Nielsen wrote: Jean-Francois Arcand wrote: Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Works for me! You might consider moving o.a.c.startup.SecurityClassLoad.java into o.a.c.security also since it is directly related to use of the SecurityManager. That's a good idea. I will do that. Is this change just in Tomcat 5? Yes, but I can port easily the change in Tomcat 4 also. Actually, the list of package access/definition are harcoded in that class. I would like to propose we move this package list into a Tomcat.security file following the J2SE format (see below). This way if people needs accesses to a package, they will have the opportunity to do it with having to recompile Catalina. If someone needs access to a restricted package they can grant the appropriate RuntimePermission in their catalina.policy. What packages need restrictions rarely change. Moving the list of packages into a Global variable would make it easier to change these the rare times we need to. But I am -1 for adding a new config file just for this. If somone has their own packages which they feel need restrictions they can always update their own $JAVA_HOME/jre/lib/security/java.security file. o.a.c.security.SecurityConfig currently contains 2 global variables: PACKAGE_ACCESS and PACKAGE_DEFINITION. :-) OK then I will leave it like that. I would consider adding a section to the Secutity-Manager HOW To to explain how to change those settings. Righ now, some Watchdog tests are failling because they need accesses to o.a.t.util, and yesterday, we have started protecting this package. Either grant the appropriate permissions where needed in catalina.policy Ya, but I have to give access to the entire package. No problem for Watchdog, but I prefer the public folder. This way we don't need to change the catalina.policy file everytime we run Watchdog. or wrap more code with doPrivileged() in catalina methods which need it. There are classes or sub packages in org.apache.tomcat.* which need to be restricted. But are the classes which are causing the failure ones which are sensitive from a security standpoint. util.http.ValuesEnumerator util.http.NamesEnumerator I don't think they are sensitive. We have the same issue with o.a.c.u.ParameterMap If not, perhaps those classes should be moved into a different package which is not restricted. +1 I think we should consider having a package in each catalina project where we expose classes to webapp. The easiest way be to create a publicClasses package under each sub-project. Since there is not a lot of classes like that, it should be easy ( I can do it). Any recommendation for the package name? If this isn't workable then either grant the appropriate permissions where needed in catalina.policy or wrap more code with doPrivileged() in catalina methods which need it. I prefer the public package instead of doPrivilege block. SecurityManager related changes and subsequent testing with the default policy file and a very strict policy file can be a very painstaking process. I am happy to more developers getting involved in this area of Tomcat. :-) Regards, ;-) Thanks, -- Jeanfrancois Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspRuntimeLibrary.java
luehe 2002/10/16 14:54:58
Modified:jasper2/src/share/org/apache/jasper/runtime
JspRuntimeLibrary.java
Log:
Output null instead of empty string for null property values in
jsp:getProperty
Revision ChangesPath
1.7 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
Index: JspRuntimeLibrary.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JspRuntimeLibrary.java9 Oct 2002 20:21:52 - 1.6
+++ JspRuntimeLibrary.java16 Oct 2002 21:54:58 - 1.7
@@ -285,7 +285,7 @@
//---
// __begin toStringMethod
public static String toString(Object o) {
-return (o == null) ? : o.toString();
+return String.valueOf(o);
}
public static String toString(byte b) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler PageDataImpl.java
luehe 2002/10/16 16:23:53
Modified:jasper2/src/share/org/apache/jasper/compiler
PageDataImpl.java
Log:
Fixed 4764102: XML view of jsp page contains jsp:root elements nested
in other jsp:root element
Revision ChangesPath
1.8 +15 -7
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java
Index: PageDataImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- PageDataImpl.java 16 Oct 2002 20:15:32 - 1.7
+++ PageDataImpl.java 16 Oct 2002 23:23:53 - 1.8
@@ -175,7 +175,10 @@
public void visit(Node.Root n) throws JasperException {
visitBody(n);
- root.setAttributes(rootAttrs);
+ if (n == this.root) {
+ // top-level page
+ this.root.setAttributes(rootAttrs);
+ }
}
public void visit(Node.JspRoot n) throws JasperException {
@@ -199,7 +202,7 @@
visitBody(n);
if (n == this.root) {
// top-level jsp:root element
- root.setAttributes(rootAttrs);
+ this.root.setAttributes(rootAttrs);
}
}
@@ -211,7 +214,7 @@
if (attrs != null) {
String location = attrs.getValue(uri);
if (location == null) {
- // JSP 2.0 CLARIFICATION NEEDED
+ // XXX JSP 2.0 CLARIFICATION NEEDED
location = attrs.getValue(tagdir);
}
String prefix = attrs.getValue(prefix);
@@ -247,7 +250,12 @@
* Visits root node of JSP page in JSP syntax.
*/
public void visit(Node.Root n) throws JasperException {
- appendTag(JSP_ROOT, n.getAttributes(), n.getBody());
+ if (n == this.root) {
+ // top-level page
+ appendTag(JSP_ROOT, n.getAttributes(), n.getBody());
+ } else {
+ visitBody(n);
+ }
}
/*
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.0.3 doesn't deploy WAR files with particular names
HI I was faced with a really strange problem today. when I wanted Tomcat to use a WAR file named wiponline.war, the server seemingly did not recognize it as a real web application. Despite of the server.xml setting UnpackWARs=true Tomcat didn't create a new directory in webapps. After only renaming the file to any other name e.g. wipOnline.war, WIPonline.war or wip-online.war the trouble was gone ! The app was loaded and executed without any difficulties. Now I wonder, why Tomcat can't cope with wiponline.war. I haven't heard anything about webapps need to have a special name. It rather seems to be some buggy feature ... tia Markus -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0.3 doesn't deploy WAR files with particular names
The appropriate forum for that type of questions will be first under tomcat-user mailling list :-) I've just rename one of my war wiponline.war file without any problems. So it is not related to Tomcat. Maybe you JDK have a bug? -- Jeanfrancois Markus Zänglein wrote: HI I was faced with a really strange problem today. when I wanted Tomcat to use a WAR file named wiponline.war, the server seemingly did not recognize it as a real web application. Despite of the server.xml setting UnpackWARs=true Tomcat didn't create a new directory in webapps. After only renaming the file to any other name e.g. wipOnline.war, WIPonline.war or wip-online.war the trouble was gone ! The app was loaded and executed without any difficulties. Now I wonder, why Tomcat can't cope with wiponline.war. I haven't heard anything about webapps need to have a special name. It rather seems to be some buggy feature ... tia Markus -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler PageDataImpl.java
luehe 2002/10/16 16:53:02
Modified:jasper2/src/share/org/apache/jasper/compiler
PageDataImpl.java
Log:
Fixed 4764157: jsp:text elements in the XML view of a JSP page
contain no jsp:id attribute
Revision ChangesPath
1.9 +11 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java
Index: PageDataImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- PageDataImpl.java 16 Oct 2002 23:23:53 - 1.8
+++ PageDataImpl.java 16 Oct 2002 23:53:02 - 1.9
@@ -456,7 +456,14 @@
private void appendText(char[] text, boolean createJspTextElement) {
if (createJspTextElement) {
- buf.append(JSP_TEXT_START);
+ buf.append().append(JSP_TEXT);
+ buf.append(\n);
+
+ // append jsp:id
+ buf.append( ).append(jsp:id).append(=\);
+ buf.append(jspId++).append(\\n);
+ buf.append(\n);
+
appendCDATA(text);
buf.append(JSP_TEXT_END);
} else {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
WEB.XML not reloaded???
Anyone noticed that the web.xml doesn't get reloaded when I reload a deployed context under 4.0? Or is it me being stupid? Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] ClassLoader hell. Again.
This time I have problems with commons-logging. It seems org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JCategoryLog does not implement Log at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:435) It seems Log is loaded by the common loader, Log4JCategoryLog by the webapp loader. And they don't match. Same thing works fine in 4.1.12. I can fix this by moving commons-logging and log4j at top level, but that's just a workaround. Remy - any idea of what changed ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13715] New: - can't do include of fragment named .jspf
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13715. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13715 can't do include of fragment named .jspf Summary: can't do include of fragment named .jspf Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I just tried renaming all my included JSP page fragments to use the extension .jspf and discovered that if I try to do a pageContext.include of one of these fragments, it bombs with the exception below. If you're curious, the reason why I am doing a pageContext.include is that the fragments are composed into a page with my template tag library. This bug is very reproducible. I go back and forth renaming my banner fragment banner.jsp and banner.jspf and it only fails when its named .jspf. It fails the same way on Tomcat and J2EE SDK 1.4. 2002-10-16 17:30:54 ApplicationDispatcher[/bookstore3] Servlet.service() for servlet default threw exception java.lang.IllegalStateException at org.apache.jasper.runtime.ServletResponseWrapperInclude.getOutputStream(ServletResponseWrapperInclude.java:110) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1022) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:506) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:194) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:727) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:616) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:530) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:833) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:427) at template.InsertTag.doEndTag(Unknown Source) at org.apache.jsp.template_jsp._jspx_meth_tt_insert_1(template_jsp.java:912) at org.apache.jsp.template_jsp._jspService(template_jsp.java:100) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:315) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:194) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:727) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:464) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356) at Dispatcher.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:194) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:271) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at
Re: WEB.XML not reloaded???
Pier Fumagalli wrote: Anyone noticed that the web.xml doesn't get reloaded when I reload a deployed context under 4.0? Yup, that is the way it works. A reload doesn't reload the web.xml. To force web.xml to reload you have to do a stop/start. It hasn't been fixed in Tomcat 4.1 either. Or is it me being stupid? No comment. ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler PageDataImpl.java
luehe 2002/10/16 18:35:46
Modified:jasper2/src/share/org/apache/jasper/compiler
PageDataImpl.java
Log:
Fixed default JSP version number in XML view at 2.0 (was: 1.2)
Revision ChangesPath
1.10 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java
Index: PageDataImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageDataImpl.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- PageDataImpl.java 16 Oct 2002 23:53:02 - 1.9
+++ PageDataImpl.java 17 Oct 2002 01:35:46 - 1.10
@@ -94,7 +94,7 @@
public class PageDataImpl extends PageData implements TagConstants {
private static final String JSP_NAMESPACE = http://java.sun.com/JSP/Page;;
-private static final String JSP_VERSION = 1.2;
+private static final String JSP_VERSION = 2.0;
private static final String CDATA_START_SECTION = ![CDATA[\n;
private static final String CDATA_END_SECTION = ]]\n;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] CoyoteRequest.doGetSession
Jean-Francois Arcand wrote: Glenn Nielsen wrote: Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. Eum...why waiting for a security issue (joke: we are not Microsoft ;-) ). Spending time trying to demonstrate a security hole will take as much time as reducing the doPrivilege block. I understand your point but still, I consider the doPrivilege block too large. And still, when Tomcat is used as it is (with the default SecurityManager), the doPrivilege block is *not* required. For a lot of Tomcat users, we are forcing a doPrivilege block. Correct me if I'm wrong, but only JDBCStore and FileStore needs to be changed. I volonteer to make the extra work. It isn't the size of the block of code that matters... Its how the code within that block could pose a security risk. From a security standpoint I don't see any possible exploits. There may be a slight performance improvement for those requests where a session is used by moving the doPrivileged out of the critical path. From just a performance perspective I would want to profile Tomcat to determine where efforts could be best spent to improve performance. Then spend time on the biggest bottleneck to performance found rather than on this. It will require that the documentation for how to write a Manager/Store be updated to discuss this issue. It will also require alot of testing to make sure that you find _all_ the places where a doPrivileged is needed. That means trying all the Manager/Store implementations which come with Tomcat and trying different configuration options. Sounds like alot of work to me. I know I don't have the time to make a change like this for the minimal benefit I see. But if you have the time and want to implement this, go ahead, its your itch. :-) Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: WEB.XML not reloaded???
On Wed, 16 Oct 2002, Glenn Nielsen wrote: Date: Wed, 16 Oct 2002 20:33:43 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: WEB.XML not reloaded??? Pier Fumagalli wrote: Anyone noticed that the web.xml doesn't get reloaded when I reload a deployed context under 4.0? Yup, that is the way it works. A reload doesn't reload the web.xml. To force web.xml to reload you have to do a stop/start. It hasn't been fixed in Tomcat 4.1 either. Think of it as a feature and not a bug :-). You can reload faster (if all you did is recompile classes) or slower (if you changed web.xml) as necessary for your particular scenario. Or is it me being stupid? No comment. ;-) Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default build.xml
patrickl2002/10/16 20:00:03
Modified:.build.properties.default build.xml
Log:
Adjust location of commons-launcher.jar. It is back in the dist/bin directory of
its build location like it was when the code was in jakarta-commons-sandbox/daemon.
Revision ChangesPath
1.44 +2 -2 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- build.properties.default 11 Oct 2002 15:16:41 - 1.43
+++ build.properties.default 17 Oct 2002 03:00:03 - 1.44
@@ -63,7 +63,7 @@
commons-launcher.home=${base.path}/commons-launcher
commons-launcher.lib=${commons-launcher.home}
commons-launcher.bin=${commons-launcher.home}/bin
-commons-launcher.jar=${commons-launcher.home}/commons-launcher.jar
+commons-launcher.jar=${commons-launcher.home.bin}/commons-launcher.jar
commons-launcher.bootstrap.class=${commons-launcher.bin}/LauncherBootstrap.class
commons-launcher.loc=jakarta-commons-sandbox/launcher
1.46 +1 -1 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- build.xml 15 Oct 2002 20:44:59 - 1.45
+++ build.xml 17 Oct 2002 03:00:03 - 1.46
@@ -800,7 +800,7 @@
param name=destfile value=${commons-launcher.jar}/
/antcall
copy
- file=${commons-launcher.home}/dist/commons-launcher.jar
+ file=${commons-launcher.home}/dist/bin/commons-launcher.jar
tofile=${commons-launcher.jar}
/
copy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Fernando Perez
I'm Tomcat learner Where need declared servlets to run this ? Where put xxx.class. in Webapps folder? Thank for all. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] ClassLoader hell. Again.
Answering my own mail, it seems Log is loaded twice, once during init ( and it may be related with my setup, as I have few log uses in the startup code ), and then it is loaded again from the webapp loader, but this time it's a different instance ( due to reverse order ). And somehow the check for assignment happens with the original Log instance. If this is correct - we can either make commons-logging(-api) a special case, or make sure it is not used in any code from the common loader ( the use from the container loader should be ok ). I love ClassLoaders :-) Costin Costin Manolache wrote: This time I have problems with commons-logging. It seems org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Log4JCategoryLog does not implement Log at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:435) It seems Log is loaded by the common loader, Log4JCategoryLog by the webapp loader. And they don't match. Same thing works fine in 4.1.12. I can fix this by moving commons-logging and log4j at top level, but that's just a workaround. Remy - any idea of what changed ? Costin -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jakarta-tomcat-connectors/jk will no longer build
Remy, Since the org.apache.catalina.connector.HttpResponseBase was removed from jakarta-tomcat-catalina, a clean Tomcat 5 build now breaks when compiling jakarta-tomcat-connectors/jk. Does HttpResponseBase need to be added back?: Thanks, Patrick [javac] Compiling 44 source files to /export/pluby/tomcat/jakarta-tomcat-connectors/jk/build/classes [javac] /export/pluby/tomcat/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java:75: cannot resolve symbol [javac] symbol : class HttpRequestBase [javac] location: package connector [javac] import org.apache.catalina.connector.HttpRequestBase; [javac] ^ [javac] /export/pluby/tomcat/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java:86: cannot resolve symbol -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Fernando Perez
In WEB-INF/classes. -Original Message- From: Fernando Perez [mailto:[EMAIL PROTECTED]] Sent: Sat 10/17/1998 10:57 PM To: Tomcat Developers List Cc: Subject: Fernando Perez I'm Tomcat learner Where need declared servlets to run this ? Where put xxx.class. in Webapps folder? Thank for all. [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] winmail.dat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: WEB.XML not reloaded???
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 17, 2002 11:53 AM To: Tomcat Developers List Subject: Re: WEB.XML not reloaded??? On Wed, 16 Oct 2002, Glenn Nielsen wrote: Date: Wed, 16 Oct 2002 20:33:43 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: WEB.XML not reloaded??? Pier Fumagalli wrote: Anyone noticed that the web.xml doesn't get reloaded when I reload a deployed context under 4.0? Yup, that is the way it works. A reload doesn't reload the web.xml. To force web.xml to reload you have to do a stop/start. It hasn't been fixed in Tomcat 4.1 either. I tested reloading web.xml on tomcat 4.0.5 and 4.1.12 and the containers showed unstable results, i.e. sometimes worked fine but sometimes didn't work. Think of it as a feature and not a bug :-). You can reload faster (if all you did is recompile classes) or slower (if you changed web.xml) as necessary for your particular scenario. I checked out the related document. http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html Signal an existing application to shut itself down and reload. This can be useful when you've recompiled classes on an application that is not configured with the reloadable=true attribute in its Context entry in $CATALINA_HOME/conf/server.xml, or when you've made other changes (such as to conf/web.xml) that are not automatically recognized. I think that reloading an application ideally means reloading classes, libs, and web.xml belonging to the application. However, so far developers have considered it as reloading just classes, in particular, servlets. I suggest making the above sentences of the documentation clearer for users not to be puzzled with reload concept and adding some guide about what is the current status of tomcat's implementing this feature. In addition, you mentioned faster and slower reload, which seems to me like auto-implicit and manual-explicit reload. Am I right on that? Or could you explain more about faster and slower with some concrete example? Or is it me being stupid? No comment. ;-) Craig -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] IAS Independent Java Technology Evangelist http://www.iasandcb.pe.kr Jakarta Seoul Project Coordinator http://jakarta.apache-korea.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-tomcat-connectors/jk will no longer build
Patrick Luby wrote: Remy, Since the org.apache.catalina.connector.HttpResponseBase was removed from jakarta-tomcat-catalina, a clean Tomcat 5 build now breaks when compiling jakarta-tomcat-connectors/jk. Does HttpResponseBase need to be added back?: No, the tomcat4 package shouldn't compile with tomcat5. I think we need a way to distinguish tomcat4 from tomcat5 in the conditions. Or a flag that is set by the tomcat5 build ( probably better ). Costin Thanks, Patrick [javac] Compiling 44 source files to /export/pluby/tomcat/jakarta-tomcat-connectors/jk/build/classes [javac] /export/pluby/tomcat/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java:75: cannot resolve symbol [javac] symbol : class HttpRequestBase [javac] location: package connector [javac] import org.apache.catalina.connector.HttpRequestBase; [javac] ^ [javac] /export/pluby/tomcat/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Request.java:86: cannot resolve symbol -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13700] - XML parser goes Internet when parsing a TLD
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13700. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13700 XML parser goes Internet when parsing a TLD --- Additional Comments From [EMAIL PROTECTED] 2002-10-17 05:14 --- I found the bug: The DOCTYPE declaration was actually split into two lines with a newline inside the public identifier, like this: !DOCTYPE taglib PUBLIC -//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd; It seems that Crimson does not treat the newline as white space as it should, considers the public identifier as something unknown and therefore goes to fetch the DTD as denoted by the system identifier. Putting the whole DOCTYPE declaration into a single line or at least breaking the line between public and system identifier solved the problem. BTW, how can I configure Tomcat to use another XML parser? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Vote results + Security Audit redirection
-Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache Sent: Wednesday, October 16, 2002 7:46 AM To: [EMAIL PROTECTED] Subject: Vote results + Security Audit redirection It seems the vote on a tomcat-commiter list got a majority - unless all inactive commiters start voting -1. Craig/Sam - please create the list or let me know who can do it. The intention is to have all active commiters in asap. As soon as we get the list, I think we should move the [Security Audit] and the other thread to it. Being sorry to interrupt you and not even a committer, I don't fully understand what [Cc] threads mean and do negatively. (Would someone mind explaining more or less about that?) We can forward the mails to the public list - but I would like to have the fixes in CVS and the potential releases before the information gets public. I'm all for full disclosure and public exploits - but at least if we find the bugs, we should fix them before making it public. I got a little bit curious about why finding bugs relevant to security and fixing them should be not open. I don't doubt that there are both merit and demerit of discussing those critical issues with full disclosure. Absolutely there may be some peril that some (bad) people can misuse the opened information purely exposed to help tomcat community to collaborate against security problems. Regardless of such understanding, I feel sorry about loss of the potential that more openness can give more people chances to figure out the shared troubles and remind them of importance of security at an early stage. There was also some comment about other special issues, which has not been clear to me yet. What are criteria of distinguishing committer-closed special issues and developer-open common issues? (I'm able to infer security must be one of the criteria, though.) I think some agreement among tomcat dev mailing list should be made before an issue is into tomcat committer-only mailing list. Basically, I hope every discussion among Apache Jakarta Project developers would be as open and transparent as possible. -- Costin -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] IAS Independent Java Technology Evangelist http://www.iasandcb.pe.kr Jakarta Seoul Project Coordinator http://jakarta.apache-korea.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Vote results + Security Audit redirection
IAS wrote: I got a little bit curious about why finding bugs relevant to security and fixing them should be not open. I don't doubt that there are both merit and demerit of discussing those critical issues with full disclosure. Absolutely there may be some peril that some (bad) people can misuse the opened information purely exposed to help tomcat community to collaborate against security problems. Regardless of such understanding, I feel sorry about loss of the potential that more openness can give more people chances to figure out the shared troubles and remind them of importance of security at an early stage. The problem is when the bad people find out about the security problems before they are fixed. I'm not saying that anyone subscribe to tomcat-dev is 'bad', but the list is archived and google searchable and has a lot of subscribers. All information will become public - it's just that I think it is better ( at least for the bugs we discover ) to first have a fix. You probably noticed most of the announcements on security issues from apache and many other organizations include a fix or at least workaround. It is a common practice to have the security issues forwarded first to some commiters, and then made public. And I think this should be true not only for bugs found from outside, but also from inside. There was also some comment about other special issues, which has not been clear to me yet. It's not clear to me either :-) Maybe short notices like I want to propose X as a commiter, does anyone has any objection ? - to avoid some of the unpleasant things we had in the past. That's the only example I can think of. Basically, I hope every discussion among Apache Jakarta Project developers would be as open and transparent as possible. Same for me. My main goal was to get all active commiters involved in future security issues. We are all equally responsible. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
