Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Tue, 08 Jan 2008 21:10:31 + Mark Thomas wrote: All I can suggest is start Tomcat with remote debugging enabled and when you see the error, connect, debug you way through a request and see if you can see what the security settings are and try and confirm that they match the policy file. I'll try to do this . Meanwhile, I've also seen something similar with the AJP connector. I'm pasting from the beginning of the stack traces. Sorry it's so long but it might give you some clue. This is the first stack trace after the container startup. Jan 9, 2008 9:15:25 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet action threw exception java.lang.IllegalStateException: Current state = FLUSHED, new state = CODING_END at java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEncoder.java:951) at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:537) at sun.nio.cs.StreamEncoder.flushLeftoverChar(StreamEncoder.java:223) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:282) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:130) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:216) at java.io.PrintWriter.close(PrintWriter.java:295) at astarot.web.CompressionServletResponseWrapper.finishResponse(CompressionServletResponseWrapper.java:99) at astarot.web.CompressionFilter.doFilter(CompressionFilter.java:170) 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:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:218) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at astarot.web.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) 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:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:218) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Mon, 07 Jan 2008 20:59:28 + Mark Thomas wrote: Not right now. Could you provide the full debug stack trace again please. We should at least see a different problem now the code has been changed. Here it goes: SEVERE: Servlet.service() for servlet jsp threw exception java.security.AccessControlException: org/apache/coyote/http11/Constants at org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:419) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1588) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:934) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.sendHeaders(Response.java:379) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288) at org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:95) at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:175) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:956) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:609) at org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:808) at org.apache.jasper.runtime.PageContextImpl.access$1100(PageContextImpl.java:71) at org.apache.jasper.runtime.PageContextImpl$12.run(PageContextImpl.java:766) at java.security.AccessController.doPrivileged(Native Method) at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:764) at org.apache.jsp.WEB_002dINF.view.page_jsp._jspService(page_jsp.java:438) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at org.apache.catalina.core.ApplicationDispatcher.access$000(ApplicationDispatcher.java:65) at org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:80) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:284) at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069) at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244)
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Delian Krustev wrote:
On Mon, 07 Jan 2008 20:59:28 + Mark Thomas wrote:
Not right now. Could you provide the full debug stack trace again please.
We should at least see a different problem now the code has been changed.
Here it goes:
I'm stumped. This stack trace indicates an issue with a different constant
but it looks to be pretty much the same issue.
Looking at this and the previous stack trace you provided, it seems to boil
down to org.apache.jasper.servlet.JasperLoader not being able to access
org/apache/coyote/http11/Constants or org/apache/coyote
This is just nuts. In every stack trace every class that appears above
either java.security.AccessController.doPrivileged(Native Method) or
java.lang.Thread.run(Thread.java:619) is a Tomcat internal class that is in
a jar in ${catalina.home}/lib and the policy file has set
grant codeBase file:${catalina.home}/lib/- {
permission java.security.AllPermission;
};
I just don't see how we are seeing what we are seeing.
My idea of a timing issue doesn't look right. You original suggestion of a
third-party lib monkeying around with the security manager and/or policy
looks more plausible.
All I can suggest is start Tomcat with remote debugging enabled and when
you see the error, connect, debug you way through a request and see if you
can see what the security settings are and try and confirm that they match
the policy file.
If anyone else has any ideas, now would be the time to speak up.
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 27 Dec 2007 16:04:29 +0200 Delian Krustev wrote: I'll monitor the container for the next several restarts. The problem appeared once again on the next tomcat restart. Any other ideas ? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Delian Krustev wrote: On Thu, 27 Dec 2007 16:04:29 +0200 Delian Krustev wrote: I'll monitor the container for the next several restarts. The problem appeared once again on the next tomcat restart. Any other ideas ? Not right now. Could you provide the full debug stack trace again please. We should at least see a different problem now the code has been changed. Cheers, Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 13 Dec 2007 21:54:22 + Mark Thomas wrote: Snapshot build of trunk available from: http://people.apache.org/~markt/dev/ This is the current 6.0.x trunk with the security manager optimisation reverted for the org.apache.coyote.* packages. *HEALTH WARNING* This is a snapshot for testing of this issue only. It is not a formal release. Thanks for the build Mark, and sorry for the delay of this reply. Could you please provide the patch also? I could not afford to move this instance to 6.0-trunk. I'll do the build myself and probably touch only the modified classes. Thank you -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Delian Krustev wrote: Thanks for the build Mark, and sorry for the delay of this reply. No problem. Could you please provide the patch also? I have uploaded it here. http://people.apache.org/~markt/dev/remove-sm-opt.patch I could not afford to move this instance to 6.0-trunk. I'll do the build myself and probably touch only the modified classes. OK. Let us know the results. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 27 Dec 2007 11:12:28 + Mark Thomas wrote: I have uploaded it here. http://people.apache.org/~markt/dev/remove-sm-opt.patch Thanks OK. Let us know the results. I did a build with your patch and replaced just lib/tomcat-coyote.jar . The exception did not show this time. I'll monitor the container for the next several restarts. Regards -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Delian Krustev wrote: On Tue, 11 Dec 2007 22:35:20 + Mark Thomas wrote: Are you happy to mod the code and build a patched version yourself or do you want some help? I can build a binary with the patch for you to test if you wish. I've not built Tomcat from source before, so I'll take advantage of the help you're offering. Thank you. Snapshot build of trunk available from: http://people.apache.org/~markt/dev/ This is the current 6.0.x trunk with the security manager optimisation reverted for the org.apache.coyote.* packages. *HEALTH WARNING* This is a snapshot for testing of this issue only. It is not a formal release. Happy testing! Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Tue, 11 Dec 2007 22:35:20 + Mark Thomas wrote: Are you happy to mod the code and build a patched version yourself or do you want some help? I can build a binary with the patch for you to test if you wish. I've not built Tomcat from source before, so I'll take advantage of the help you're offering. Thank you. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Delian Krustev wrote: On Wed, 05 Dec 2007 22:13:00 + Mark Thomas wrote: I am beginning to think that http://svn.apache.org/viewvc?view=revrev=505593 introduced a subtle timing issue. If Tomcat internal code causes Constants to be loaded, everything is fine. If the webapp code causes Constants to be loaded, it fails. snip/ The fix would be to revert to the (System.getSecurityManager() != null) test. I'd be glad to test the patch. Are you happy to mod the code and build a patched version yourself or do you want some help? I can build a binary with the patch for you to test if you wish. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Wed, 05 Dec 2007 22:13:00 + Mark Thomas wrote: Did it happen straight away or did it work for a while and then fail? Dec 3, 2007 10:14:24 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 152362 ms .. Dec 3, 2007 10:17:22 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.security.AccessControlException: org/apache/coyote/Constants I've tried it about 3 minutes after the restart. I am beginning to think that http://svn.apache.org/viewvc?view=revrev=505593 introduced a subtle timing issue. If Tomcat internal code causes Constants to be loaded, everything is fine. If the webapp code causes Constants to be loaded, it fails. It goes live straight away, so I suppose some request from user web application might have already been served. I've been observing this problem for quite a while, and it has been there all the time. The HTTP connector stays unused because of this problem. You might be right - may be the last time it did not appear because my test was done prior to a request to an application that triggers it. The fix would be to revert to the (System.getSecurityManager() != null) test. I'd be glad to test the patch. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
I think the problem arises because
a.public static final boolean IS_SECURITY_ENABLED =
(System.getSecurityManager() != null);
is more a macro definition than a constant definition.
But as Java does not support macros, the compiler cannot replace
occurrences of 'IS_SECURITY_ENABLED' with
'System.getSecurityManager() != null)'
b. As there are multiple classes named 'Constants' in different
packages,
there is no import declaration for org.apache.coyote.Constants in the
Http11Processor class because it would clash with
org.apache.coyote.http11.Constants.
I would guess that with an import declaration the 'Constants' class
would have been resolved earlier by the class loader.
If this is the case, there would be different ways to solve the problem:
1. use
import static org.apache.coyote.Constants.IS_SECURITY_ENABLED;
This is possible since Java 5 and allows to refer to IS_SECURITY_ENABLED
in the code without a package/class qualifier.
I am not sure if this would solve the issue, but it is an easy trial
(afaik Tomcat 6 requires Java 5 anyway).
2. org.apache.coyote.http11.Constants extends
org.apache.coyote.Constants
I have not checked if there would be name conflicts between declartions
in these packages, but if there are any,
I would try to resolve them anyway.
However, this would not allow to declare the Constants classes final.
I am not sure if this has any impact.
3. refactor the class names to avoid name clashes (CoyoteConstants,
CoyoteHttp11Constants, ...)
4. introduce a new class
package org.apache.coyote;
public final class CoyoteMacros
{
public static final boolean IS_SECURITY_ENABLED =
(System.getSecurityManager() != null);
}
- Matthias
-Original Message-
From: Delian Krustev [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 06, 2007 10:18 AM
To: Tomcat Users List
Subject: Re: AccessControlException in Coyote Http11Processor (Tomcat
6.0.14). Bug in Coyote ?
On Wed, 05 Dec 2007 22:13:00 + Mark Thomas wrote:
Did it happen straight away or did it work for a while and then fail?
Dec 3, 2007 10:14:24 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 152362 ms
..
Dec 3, 2007 10:17:22 PM org.apache.catalina.core.ApplicationDispatcher
invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.security.AccessControlException: org/apache/coyote/Constants
I've tried it about 3 minutes after the restart.
I am beginning to think that
http://svn.apache.org/viewvc?view=revrev=505593 introduced a subtle
timing
issue. If Tomcat internal code causes Constants to be loaded,
everything is
fine. If the webapp code causes Constants to be loaded, it fails.
It goes live straight away, so I suppose some request from user web
application might have already been served.
I've been observing this problem for quite a while, and it has been
there all
the time.
The HTTP connector stays unused because of this problem.
You might be right - may be the last time it did not appear because my
test
was done prior to a request to an application that triggers it.
The fix would be to revert to the (System.getSecurityManager() !=
null)
test.
I'd be glad to test the patch.
Cheers
--
Delian
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Delian Krustev wrote: Well, here we go. The problem appeared once again after the next restart. Did it happen straight away or did it work for a while and then fail? I am beginning to think that http://svn.apache.org/viewvc?view=revrev=505593 introduced a subtle timing issue. If Tomcat internal code causes Constants to be loaded, everything is fine. If the webapp code causes Constants to be loaded, it fails. The fix would be to revert to the (System.getSecurityManager() != null) test. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 29 Nov 2007 07:51:07 + Mark Thomas wrote: It should show more information. If there is something subtle going on with the permissions then it should make it easier to figure out. Well, here we go. The problem appeared once again after the next restart. I've hidden the username and the domain since they are irrelevant anyway. This happens with all the users, apps and URLs once the problem appears. It seem that the files under the work directory need: java.lang.RuntimePermission accessClassInPackage.org.apache.coyote and it is not granted each time. Sorry for the long stack trace. access: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.coyote) java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1206) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:313) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:273) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1557) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:934) at org.apache.coyote.Response.action(Response.java:181) at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:563) at org.apache.coyote.Response.doWrite(Response.java:560) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:353) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:325) at org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:242) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:190) at org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:196) at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:81) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:438) at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:143) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342) at org.apache.jsp.WEB_002dINF.view.page_jsp._jspService(page_jsp.java:351) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at sun.reflect.GeneratedMethodAccessor324.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 29 Nov 2007 07:51:07 + Mark Thomas wrote: It should show more information. If there is something subtle going on with the permissions then it should make it easier to figure out. The container has been restarted today. Oddly enough the exception does not show now. I'll keep the option -Djava.security.debug=access,failure and will post more information if this happens again. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Hi Mark,
On Tue, 27 Nov 2007 18:21:20 + Mark Thomas wrote:
Can you run the faulty instance with:
-Djava.security.debug=access,failure
and report the failure message.
I thought on this, but the exception looks pretty self explanatory.
I'll try it anyway, in case anything new comes up. The machine is used in
production so this will be applied on the next tomcat restart(might be
several days from now).
If you can reproduce this at will then
-Djava.security.debug=all
would be better but it will generate lots of log data
I have also seen problems with policy files where I have had to use
${file.separator} rather than / but that was with java.io.FilePermission on
Windows rather than in the codebase.
Cheers
--
Delian
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Delian Krustev wrote: Hi Mark, On Tue, 27 Nov 2007 18:21:20 + Mark Thomas wrote: Can you run the faulty instance with: -Djava.security.debug=access,failure and report the failure message. I thought on this, but the exception looks pretty self explanatory. I'll try it anyway, in case anything new comes up. The machine is used in production so this will be applied on the next tomcat restart(might be several days from now). It should show more information. If there is something subtle going on with the permissions then it should make it easier to figure out. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Hi all,
I'm running several similarly configured Tomcat containers all using
security manager.
On one of the instances I'm getting the following exception from the HTTP
connector:
Nov 26, 2007 7:42:19 PM org.apache.catalina.connector.CoyoteAdapter service
SEVERE: An exception or error occurred in the container during the request
processing
java.security.AccessControlException: org/apache/coyote/Constants
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1557)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:934)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.sendHeaders(Response.java:379)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)
at org.apache.catalina.connector.Response.finishResponse(Response.java:486)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:287)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Nov 26, 2007 7:42:19 PM org.apache.coyote.http11.Http11Processor process
SEVERE: Error finishing response
java.security.AccessControlException: org/apache/coyote/Constants
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1557)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:934)
at org.apache.coyote.Response.action(Response.java:181)
at
org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:379)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
At the same time the AJP connector works fine.
The security policy is a bit looser than the one distributed with tomcat 6.0.14:
start catalina.policy
grant codeBase file:${java.home}/lib/- {
permission java.security.AllPermission;
};
grant codeBase file:${java.home}/jre/lib/ext/- {
permission java.security.AllPermission;
};
grant codeBase file:${java.home}/../lib/- {
permission java.security.AllPermission;
};
grant codeBase file:${java.home}/lib/ext/- {
permission java.security.AllPermission;
};
grant codeBase file:${catalina.home}/bin/commons-daemon.jar {
permission java.security.AllPermission;
};
grant codeBase file:${catalina.home}/bin/tomcat-juli.jar {
permission java.security.AllPermission;
};
grant codeBase file:${catalina.home}/bin/bootstrap.jar {
permission java.security.AllPermission;
};
grant codeBase file:${catalina.home}/lib/- {
permission java.security.AllPermission;
};
grant {
permission java.util.PropertyPermission *, read;
permission java.lang.RuntimePermission getAttribute;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.jasper.runtime;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.jasper.runtime.*;
permission java.net.SocketPermission *:1-, connect;
permission java.net.SocketPermission localhost:1-, connect;
permission java.io.FilePermission ${catalina.home}/lib/-, read;
permission java.io.FilePermission ${java.home}/-, read;
permission java.lang.RuntimePermission accessDeclaredMembers;
permission java.lang.RuntimePermission getClassLoader;
permission java.lang.RuntimePermission getProtectionDomain;
permission java.lang.reflect.ReflectPermission suppressAccessChecks;
permission ognl.OgnlInvokePermission *;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.tomcat.dbcp.collections;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.tomcat.dbcp.pool.impl;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.tomcat.dbcp.dbcp;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.tomcat.dbcp.pool;
};
end catalina.policy
catalina.properties is unmodified .
The connectors are configured like this:
Connector
port=8080
protocol=HTTP/1.1
maxThreads=150
connectionTimeout=2
redirectPort=443 /
Connector port=8009
enableLookups=false
redirectPort=443
protocol=AJP/1.3
backlog=100
connectionTimeout=5000
maxThreads=300 /
My guess is that either this is a bug in the Coyote HTTP connector
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Delian Krustev wrote:
My guess is that either this is a bug in the Coyote HTTP connector or
the security policy is not strict enough and one of the
installed applications (third party, I don't have access to the source)
modifies the security manager somehow. My modifications
to the policy do not appear to grant such permissions to the webapps, so if
the assumption is right it's a bug in the distributed catalina.policy.
Webapps do have some default permissions (files and JNDI) so it is possible
that these are all the app requires to run.
The policy file as is should mean the code has access to the class. Not
sure why it fails.
Can you run the faulty instance with:
-Djava.security.debug=access,failure
and report the failure message.
If you can reproduce this at will then
-Djava.security.debug=all
would be better but it will generate lots of log data
I have also seen problems with policy files where I have had to use
${file.separator} rather than / but that was with java.io.FilePermission on
Windows rather than in the codebase.
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
