Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default

2002-10-26 Thread Glenn Nielsen
Hmmm...

I did some reviews of CVS for the code which sets the context dir
FilePermission.  I had made a cut n paste mistake when changing code related
to this which would have prevented the context dir FilePermission
from being created.  This bug only existed for 6 hours in CVS before
I fixed it.  This also the same day that the Tomcat 4.1.12
version was tagged in CVS.  4.1.12 may have been released with this bug.

Please try Tomcat 4.1.13 and see if the problem still exists.

Regards,

Glenn

Aditya wrote:

Glenn,

On Fri, Oct 25, 2002 at 08:40:28AM -0500, Glenn Nielsen wrote:


I suspect that for some reason the Context does not have a context 
directory.  Add


FWIW, I'm not running the context from a WAR file -- it's just the examples
context that comes with the default install.



String docBase = context.getRealPath(/); to your test jsp and see if it 
returns null.


could you fully qualify the context Class -- if it's the same as:

  pageContext.getServletContext().getRealPath(/);

then docBase returns /usr/local/tomcat/webapps/examples/ correctly. ie. if I
have just the following in the JSP:

  String fullPath = pageContext.getServletContext().getRealPath(/test2.new);
  out.println(brfullPath:  + fullPath);

  String docBase = pageContext.getServletContext().getRealPath(/);
  out.println(brdocBase:  + docBase);

I correctly get:

  fullPath: /usr/local/tomcat/webapps/examples/test2.new
  docBase: /usr/local/tomcat/webapps/examples/

however when I add:

  java.io.File foo = new java.io.File(fullPath);
  if (foo.exists())
out.println(Exists:  + fullPath);
else {
out.println(does not exist);
}

to the JSP I get the old:

  java.io.FilePermission /usr/local/tomcat/webapps/examples/test2.new read

the debug output is appended below (let me know if you want more) -- I set all
the debug flats in server.xml to 9.



Also try setting the debug attributes in your server.xml to 9 and capture 
the debug output.


from localhost_examples_log:

2002-10-25 14:25:19 Authenticator[/examples]: Security checking request GET
/examples/jsp/test.jsp
2002-10-25 14:25:19 Authenticator[/examples]:  Checking constraint
'SecurityConstraint[Protected Area]' against GET /jsp/test.jsp -- false
2002-10-25 14:25:19 Authenticator[/examples]:  No applicable constraint
located
2002-10-25 14:25:19 Authenticator[/examples]:  Not subject to any constraint
2002-10-25 14:25:19 StandardContext[/examples]: Mapping
contextPath='/examples' with requestURI='/examples/jsp/test.jsp' and
relativeURI='/jsp/test.jsp'
2002-10-25 14:25:19 StandardContext[/examples]:   Trying exact match
2002-10-25 14:25:19 StandardContext[/examples]:   Trying prefix match
2002-10-25 14:25:19 StandardContext[/examples]:   Trying extension match
2002-10-25 14:25:19 StandardContext[/examples]:  Mapped to servlet 'jsp' with
servlet path '/jsp/test.jsp' and path info 'null' and update=true
2002-10-25 14:25:27 StandardWrapperValve[jsp]: Servlet.service() for servlet
jsp threw exception
org.apache.jasper.JasperException: access denied (java.io.FilePermission
/usr/local/tomcat/webapps/examples/test2.new read)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:248)
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:247)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
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:471)
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

Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default

2002-10-25 Thread Aditya
 On Thu, 24 Oct 2002 22:59:59 -0500, Glenn Nielsen [EMAIL PROTECTED] said:
 Gettting the latest version from CVS won't fix your problem. I still
 think the problem is somewhere in your configuration.

I've installed the 4.1.12 tarball from the website and am running it
without modification other than adding the test jsp to
webapps/examples/jsp/test.jsp

I've now tried it under:

 Solaris/JDK1.4 with 4.1.12-LE 
 FreeBSD/JDK1.3.1 with 4.1.12
 Debian/JDK1.3.1 with 4.1.12

with the same result.

 You might try posting the SecurityManager debug output when the
 FilePermission read is denied.  Including the stack trace and the
 ProtectionDomain which failed.

Okay, here goes -- as I mentioned before, I see this as the exception:

org.apache.jasper.JasperException: access denied (java.io.FilePermission 
/usr/local/tomcat/webapps/examples/test2.new read)

and with the following CATALINA_OPTS=-Djava.security.debug=access,failure I get this 
in logs/catalina.out:

access: access denied (java.io.FilePermission 
/usr/local/tomcat/webapps/examples/test2.new read)
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1071)
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:259)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.SecurityManager.checkRead(SecurityManager.java:887)
at java.io.File.exists(File.java:677)
at org.apache.jsp.test_jsp._jspService(test_jsp.java:53)
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:204)
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:247)
at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
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:471)
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.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:256)

Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default

2002-10-25 Thread Glenn Nielsen
The ProtectionDomain shows that Jasper2 is creating a read FilePermission for the scratch
(work) dir.  But you are correct, there is no read FilePermission listed for the context
directory.

The same block of code in org.apache.jasper.compiler.JspRuntimeContext which  creates the
scratch (work) dir read FilePermissionalso creates the context dir read FilePermission.
In cases where the context is running from a war file there will be no context directory
so the below getRealPath(/) would return null. When there is no context directory the read
FilePermission is granted to the scratch directory.

I suspect that for some reason the Context does not have a context directory.  Add
String docBase = context.getRealPath(/); to your test jsp and see if it returns null.
Also try setting the debug attributes in your server.xml to 9 and capture the debug output.

// Get the permissions for the web app context
String docBase = context.getRealPath(/);
if( docBase == null ) {
docBase = options.getScratchDir().toString();
}
if (!docBase.endsWith(File.separator)){
docBase = docBase + File.separator;
}


Regards,

Glenn

Aditya wrote:

On Thu, 24 Oct 2002 22:59:59 -0500, Glenn Nielsen [EMAIL PROTECTED] said:
Gettting the latest version from CVS won't fix your problem. I still
think the problem is somewhere in your configuration.



I've installed the 4.1.12 tarball from the website and am running it
without modification other than adding the test jsp to
webapps/examples/jsp/test.jsp

I've now tried it under:

 Solaris/JDK1.4 with 4.1.12-LE 
 FreeBSD/JDK1.3.1 with 4.1.12
 Debian/JDK1.3.1 with 4.1.12

with the same result.


You might try posting the SecurityManager debug output when the
FilePermission read is denied.  Including the stack trace and the
ProtectionDomain which failed.



Okay, here goes -- as I mentioned before, I see this as the exception:

org.apache.jasper.JasperException: access denied (java.io.FilePermission /usr/local/tomcat/webapps/examples/test2.new read)

and with the following CATALINA_OPTS=-Djava.security.debug=access,failure I get this in logs/catalina.out:

access: access denied (java.io.FilePermission /usr/local/tomcat/webapps/examples/test2.new read)
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1071)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:259)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.SecurityManager.checkRead(SecurityManager.java:887)
at java.io.File.exists(File.java:677)
at org.apache.jsp.test_jsp._jspService(test_jsp.java:53)
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:204)
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:247)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
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:471)
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 

Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default

2002-10-24 Thread Jean-Francois Arcand


Aditya wrote:


Glenn,

On Thu, Oct 24, 2002 at 10:03:47AM -, [EMAIL PROTECTED] wrote:
 

This must be a problem in your local system configuration.
Check the unix file ownerhsip and permissions for test2.new.
   


I've done that and the fact is that it works fine without the security manager
so it's not a unix file ownership and permissions problem.

 

Also try running Tomcat with java property -Djava.security.debug=access,failure
defined and then check the security manager debug output.
   


yup, done that and the output has nothing more than the failure of read
permissions.

 

I just tested the jsp you posted with a fresh build of Tomcat 4.1 from
the CVS head (What will be Tomcat 4.1.13) and Jasper 2.  The FilePermission
read for the context directory is being granted automatically and the JSP works.
   


I just read the 4.1.13 announcement from Remy and it has the following note:

IMPORTANT NOTE: Security manager functionality is broken in this
milestone. This will be fixed in the next milestone. This milestone will
not be proposed for official release, and should be used for testing
purposes only.

so before I checkout a fresh copy from CVS, need I be worried about this?


No, this is not related to your problem. The SecurityManager in 4.1.13 
will throws security exception when you use:

HttpServletRequest.setContentType()
HttpServletRequest.getContentType()
HttpServletRequest.getParameters()
HttpServletRequest.getMimeHeaders()
HttpServletRequest.getCharacterEncoding()

HttpServletResponse.getContentType()
HttpServletResponse.setContentType()
HttpServetResponse.getHeaders()
HttpServetResponse..getHeader()

And it should *not*.

-- Jeanfrancois





Thanks,
Adi

--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org


 



Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default

2002-10-24 Thread Glenn Nielsen
Aditya wrote:

Glenn,

On Thu, Oct 24, 2002 at 10:03:47AM -, [EMAIL PROTECTED] wrote:


This must be a problem in your local system configuration.
Check the unix file ownerhsip and permissions for test2.new.



I've done that and the fact is that it works fine without the security manager
so it's not a unix file ownership and permissions problem.



Also try running Tomcat with java property -Djava.security.debug=access,failure
defined and then check the security manager debug output.



yup, done that and the output has nothing more than the failure of read
permissions.



I just tested the jsp you posted with a fresh build of Tomcat 4.1 from
the CVS head (What will be Tomcat 4.1.13) and Jasper 2.  The FilePermission
read for the context directory is being granted automatically and the JSP works.



I just read the 4.1.13 announcement from Remy and it has the following note:

 IMPORTANT NOTE: Security manager functionality is broken in this
 milestone. This will be fixed in the next milestone. This milestone will
 not be proposed for official release, and should be used for testing
 purposes only.

so before I checkout a fresh copy from CVS, need I be worried about this?



Tomcat and Jasper1/Jasper2 have granted web applications and JSP pages read access to
their own context directory since the SecurityManager was first implemented years
ago.  I don't recall there ever being a bug with this or that it has changed.
I was just verifying that the code hadn't been inadvertently broken.

Gettting the latest version from CVS won't fix your problem. I still think the
problem is somewhere in your configuration.

You might try posting the SecurityManager debug output when the FilePermission read
is denied.  Including the stack trace and the ProtectionDomain which failed.

Regards,

Glenn


--
To unsubscribe, e-mail:   mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org