Security problem
When trying a recently unpacked 5.5.11, started with -security, I get an exception the first time I try to check the root index.jsp. Anyone know what I am doing wrong? Cheers, -- Gunnar Brading SEVERE: Servlet.service() for servlet org.apache.jsp.index_jsp threw exception java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.coyote.http11) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) 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.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:429) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1602) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:961) at org.apache.coyote.Response.action(Response.java:180) at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:573) at org.apache.coyote.Response.doWrite(Response.java:555) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:361) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:299) at org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:235) at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336) at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404) at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:184) at org.apache.tomcat.util.buf.C2BConverter.flushBuffer(C2BConverter.java:127) at org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:536) at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:259) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:456) at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:142) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:118) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:325) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:341) at org.apache.jsp.index_jsp._jspService(index_jsp.java:50) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 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:585) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243) 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:275) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:161) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:245) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:50) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:156) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:152) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11
Re: Functionality of run-as for Servlets
Your suggestion is very good, but doesn't work, as I understand it, when not using a SecurityManager. Subject.getSubject() returns null. Now I myself think it is a great idea to use a security-manager at all times, but when writing an application it seems like a good idea not to make that assumption. Is it really a requirement to have a SecurityManager for Subject to be useful? It seems like a construct like the one you suggest should work even without one. Cheers, -- Gunnar Gunnar Brading wrote: I have been in need of using the run-as tag in a Tomcat-only environment... Is this possible? Reading the source indicates that it wouldn't be possible to get the information about the role the context currently is in. Using the requests in-role methods of course tells me about the user, and not the context. Have I come to the right conclusion? No ;-) You can get access to the Subject by doing Subject.getSubject(AccessController.getContext()) Reading the specs tells me that the functionality is meant for transferring roles to EJB's. Some documentation I found at Sun indicates though that even web-applications should be able to use this. The way SJSAS 8.x is doing that is by using the Subject and then the principal(s) associated with the Subject. -- Jeanfrancois Anyone got more information about this? Cheers, -- gunnar -- Gunnar Brading, Astrogator AB - High Performance Networks Interactive Media Email; [EMAIL PROTECTED] Address; Rorstrandsgatan 30A, 113 40 STOCKHOLM Office: +46 8 5456 0010 Fax: +46 8 5456 0011 Cellular: +46 70 778 2 877 The scientist describes what is; the engineer creates what never was - Theodore von Karman
Re: Functionality of run-as for Servlets
Following up after some testing I gave up, and just for testing thought I should use the SecurityManager. Always a good idea. But... I got to be stupid or something, but I do not get the run-as to show up anyhow. When not authenticated, the retrieved Subject gives an empty set of principals When authenticated the set of Principals only shows the authenticated users roles. The run-as doesn't seem to affect the Subject as far as I can tell. It should I guess, as Jeanfrancois said. I personally think it should, even without a SecurityManager. Any insights? Cheers, -- Gunnar Gunnar Brading wrote: Your suggestion is very good, but doesn't work, as I understand it, when not using a SecurityManager. Subject.getSubject() returns null. Now I myself think it is a great idea to use a security-manager at all times, but when writing an application it seems like a good idea not to make that assumption. Is it really a requirement to have a SecurityManager for Subject to be useful? It seems like a construct like the one you suggest should work even without one. Cheers, -- Gunnar Gunnar Brading wrote: I have been in need of using the run-as tag in a Tomcat-only environment... Is this possible? Reading the source indicates that it wouldn't be possible to get the information about the role the context currently is in. Using the requests in-role methods of course tells me about the user, and not the context. Have I come to the right conclusion? No ;-) You can get access to the Subject by doing Subject.getSubject(AccessController.getContext()) Reading the specs tells me that the functionality is meant for transferring roles to EJB's. Some documentation I found at Sun indicates though that even web-applications should be able to use this. The way SJSAS 8.x is doing that is by using the Subject and then the principal(s) associated with the Subject. -- Jeanfrancois Anyone got more information about this? Cheers, -- gunnar -- Gunnar Brading, Astrogator AB - High Performance Networks Interactive Media Email; [EMAIL PROTECTED] Address; Rorstrandsgatan 30A, 113 40 STOCKHOLM Office: +46 8 5456 0010 Fax: +46 8 5456 0011 Cellular: +46 70 778 2 877 The scientist describes what is; the engineer creates what never was - Theodore von Karman -- Gunnar Brading, Astrogator AB - High Performance Networks Interactive Media Email; [EMAIL PROTECTED] Address; Rorstrandsgatan 30A, 113 40 STOCKHOLM Office: +46 8 5456 0010 Fax: +46 8 5456 0011 Cellular: +46 70 778 2 877 The scientist describes what is; the engineer creates what never was - Theodore von Karman smime.p7s Description: S/MIME Cryptographic Signature
Functionality of run-as for Servlets
I have been in need of using the run-as tag in a Tomcat-only environment... Is this possible? Reading the source indicates that it wouldn't be possible to get the information about the role the context currently is in. Using the requests in-role methods of course tells me about the user, and not the context. Have I come to the right conclusion? Reading the specs tells me that the functionality is meant for transferring roles to EJB's. Some documentation I found at Sun indicates though that even web-applications should be able to use this. Anyone got more information about this? Cheers, -- gunnar -- Gunnar Brading, Astrogator AB - High Performance Networks Interactive Media Email; [EMAIL PROTECTED] Address; Rorstrandsgatan 30A, 113 40 STOCKHOLM Office: +46 8 5456 0010 Fax: +46 8 5456 0011 Cellular: +46 70 778 2 877 The scientist describes what is; the engineer creates what never was - Theodore von Karman smime.p7s Description: S/MIME Cryptographic Signature
