You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Simon Brooke <si...@jasmine.org.uk> on 2002/12/02 17:39:40 UTC
Access denied... to /tmp !?
Hi
I've been running things under various versions of Tomcat for a long time
now, but it's always been Tomcats I've compiled and installed myself. Now I'm
trying to get things running with the version of Tomcat which is packaged in
the Debian package 'tomcat4 4.0.3-3woody1'. The tomcat install works, and I
can install my webapp OK, and tomcat serves static pages out of my webapp
just fine. But when I try to access a Servlet, I get
Apache Tomcat/4.0.3 - HTTP Status 500 - Internal Server Error
type Exception report
message Internal Server Error
description The server encountered an internal error (Internal Server
Error) that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: Servlet.init() for servlet items threw
exception at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935
)
... usual stuf...
root cause
java.security.AccessControlException: access denied (java.io.FilePermission
/tmp read) at
java.security.AccessControlContext.checkPermission(AccessControlContext.java(
Compiled Code))
Now if I understand what's going on there, the servlet is falling over
because it can't read /tmp...
What I want to know is where this security policy is set?
--
simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
Error 1109: There is no message for this error
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Access denied... to /tmp !?
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Simon Brooke wrote:
>On Monday 02 Dec 2002 5:01 pm, Jeanfrancois Arcand wrote:
>
>
>>That's the proper behaviour. By default, a web application is only able
>>to read under the context under which it was deployed. If you want to
>>grant access to the /tmp !*be carefull*!, add the following in your
>>catalina.policy file:
>>
>>grant codeBase "file:${catalina.home}/webapps/<<your context>>/-" {
>> permission java.io.FilePermission "/tmp", "read";
>>};
>>
>>
>
>OK, this raises another issue. The problem arose because my servlet makes use
>of the maybeupload package <URL: http://www.weft.co.uk/library/maybeupload/ >
>which I wrote and maintain, but which is also used in a number of other
>people's code including Cocoon 2, so it's moderately important that it
>doesn't do stupid things.
>
>MaybeUploadServlet checks in it's init method that it's upload directory
>exists and is writable:
>
> uploadDir = new File( uploadDirPath);
>
> if ( ! uploadDir.isDirectory() || ! uploadDir.canWrite())
> throw new
> UnavailableException( "Cannot write to upload directory " +
> uploadDirPath);
>
>UploadDirPath is a runtime configurable parameter, expected to be picked up
>from the web.xml:
>
> uploadDirPath = getStringParameterValue( "upload_dir_path", config,
> uploadDirPath);
>
>However, if no value is specified in the web.xml, then currently the
>hard-coded default is /tmp; the thinking being this is it's usually a safe
>place to write stuff.
>
>Clearly, though, as you point out, this is the wrong thing to do. The obvious
>solution is to alter MaybeUploadServlet so that if no upload_dir_path is
>specified in the web.xml, to switch off the upload facility altogether,
>possibly appending a warning to the log. However I don't know who else's code
>this will hurt (and, indeed, it's interesting that I haven't had anyone else
>report this to me as a bug).
>
Because they probably runs Tomcat without the security manager, so they
can read/write from any context :-)
>
>Could anyone suggest a means of getting a 'safe' directory path for
>UploadDirPath to default to, or should I go for the 'switch off' behaviour?
>
Have you try the solution proposed by Yoav? This is probably the best
solution if you want a "tmp" directory for each web-app. If you only
want 1 directory, then the /tmp is fine (but works only on Unix).
-- Jeanfrancois
>
>Cheers
>
>Simon
>
>
>
Re: Can Filter-mappings be defined using regular expressions?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 3 Dec 2002, Stephen Riek wrote:
> Date: Tue, 3 Dec 2002 23:12:47 +0000 (GMT)
> From: Stephen Riek <st...@yahoo.co.uk>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Can Filter-mappings be defined using regular expressions?
>
>
> There's got to be a better way of writing Filter-mapping than the following, where I want to allow any URL that begins either with:
> a) /Products/* or
> b) /<2 characters>/Products/*
>
> ---------------------->8--------------------------
>
> <filter-mapping>
> <filter-name>ProductsFilter</filter-name>
> <url-pattern>/Products/*</url-pattern>
> </filter-mapping>
>
> <filter-mapping>
> <filter-name>ProductsFilter</filter-name>
> <url-pattern>/en/Products/*</url-pattern>
> </filter-mapping>
>
> <filter-mapping>
> <filter-name>ProductsFilter</filter-name>
> <url-pattern>/de/Products/*</url-pattern>
> </filter-mapping>
>
> <filter-mapping>
> <filter-name>ProductsFilter</filter-name>
> <url-pattern>/fr/Products/*</url-pattern>
> </filter-mapping>
>
> <filter-mapping>
> <filter-name>ProductsFilter</filter-name>
> <url-pattern>/es/Products/*</url-pattern>
> </filter-mapping>
>
> ---------------------->8--------------------------
>
> Using */Products/* doesn't necessarily do it (and I think wouldn't work anyway) since it would also collect match /SomeFolder/Another/Products which would be incorrect.
>
> I don't mind using the above excep that it gets messy with multiple
> filters, and I was wondering if it could be more efficient for Tomcat
> written some other way.
>
An alternative strategy would be to map your filter to "/*" (so it
receives all requests) and then programmatically check the request URI in
the filter to decide whether or not to perform the redirection action.
You could use things like regular expressions, or whatever you wanted, to
make that sort of comparison.
> Thanks,
>
> Stephen.
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Can Filter-mappings be defined using regular expressions?
Posted by "Noel J. Bergman" <no...@devtech.com>.
The Servlet Specification describes allowable mappings, and doesn't describe
regex support, which means that it isn't there. You'd have to roll your
own, which you could implement with a controlling filter.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Can Filter-mappings be defined using regular expressions?
Posted by Stephen Riek <st...@yahoo.co.uk>.
There's got to be a better way of writing Filter-mapping than the following, where I want to allow any URL that begins either with:
a) /Products/* or
b) /<2 characters>/Products/*
---------------------->8--------------------------
<filter-mapping>
<filter-name>ProductsFilter</filter-name>
<url-pattern>/Products/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ProductsFilter</filter-name>
<url-pattern>/en/Products/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ProductsFilter</filter-name>
<url-pattern>/de/Products/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ProductsFilter</filter-name>
<url-pattern>/fr/Products/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>ProductsFilter</filter-name>
<url-pattern>/es/Products/*</url-pattern>
</filter-mapping>
---------------------->8--------------------------
Using */Products/* doesn't necessarily do it (and I think wouldn't work anyway) since it would also collect match /SomeFolder/Another/Products which would be incorrect.
I don't mind using the above excep that it gets messy with multiple filters, and I was wondering if it could be more efficient for Tomcat written some other way.
Thanks,
Stephen.
---------------------------------
With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs
Re: Access denied... to /tmp !?
Posted by Simon Brooke <si...@jasmine.org.uk>.
On Monday 02 Dec 2002 5:01 pm, Jeanfrancois Arcand wrote:
> That's the proper behaviour. By default, a web application is only able
> to read under the context under which it was deployed. If you want to
> grant access to the /tmp !*be carefull*!, add the following in your
> catalina.policy file:
>
> grant codeBase "file:${catalina.home}/webapps/<<your context>>/-" {
> permission java.io.FilePermission "/tmp", "read";
> };
OK, this raises another issue. The problem arose because my servlet makes use
of the maybeupload package <URL: http://www.weft.co.uk/library/maybeupload/ >
which I wrote and maintain, but which is also used in a number of other
people's code including Cocoon 2, so it's moderately important that it
doesn't do stupid things.
MaybeUploadServlet checks in it's init method that it's upload directory
exists and is writable:
uploadDir = new File( uploadDirPath);
if ( ! uploadDir.isDirectory() || ! uploadDir.canWrite())
throw new
UnavailableException( "Cannot write to upload directory " +
uploadDirPath);
UploadDirPath is a runtime configurable parameter, expected to be picked up
from the web.xml:
uploadDirPath = getStringParameterValue( "upload_dir_path", config,
uploadDirPath);
However, if no value is specified in the web.xml, then currently the
hard-coded default is /tmp; the thinking being this is it's usually a safe
place to write stuff.
Clearly, though, as you point out, this is the wrong thing to do. The obvious
solution is to alter MaybeUploadServlet so that if no upload_dir_path is
specified in the web.xml, to switch off the upload facility altogether,
possibly appending a warning to the log. However I don't know who else's code
this will hurt (and, indeed, it's interesting that I haven't had anyone else
report this to me as a bug).
Could anyone suggest a means of getting a 'safe' directory path for
UploadDirPath to default to, or should I go for the 'switch off' behaviour?
Cheers
Simon
--
simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;; making jokes about dyslexia isn't big, it isn't clever and
;; it isn't furry.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Access denied... to /tmp !?
Posted by Jeanfrancois Arcand <jf...@apache.org>.
That's the proper behaviour. By default, a web application is only able
to read under the context under which it was deployed. If you want to
grant access to the /tmp !*be carefull*!, add the following in your
catalina.policy file:
grant codeBase "file:${catalina.home}/webapps/<<your context>>/-" {
permission java.io.FilePermission "/tmp", "read";
};
-- Jeanfrancois
Simon Brooke wrote:
>Hi
>
>I've been running things under various versions of Tomcat for a long time
>now, but it's always been Tomcats I've compiled and installed myself. Now I'm
>trying to get things running with the version of Tomcat which is packaged in
>the Debian package 'tomcat4 4.0.3-3woody1'. The tomcat install works, and I
>can install my webapp OK, and tomcat serves static pages out of my webapp
>just fine. But when I try to access a Servlet, I get
>
> Apache Tomcat/4.0.3 - HTTP Status 500 - Internal Server Error
> type Exception report
> message Internal Server Error
> description The server encountered an internal error (Internal Server
> Error) that prevented it from fulfilling this request.
> exception
> javax.servlet.ServletException: Servlet.init() for servlet items threw
> exception at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935
>)
>
>... usual stuf...
>
> root cause
> java.security.AccessControlException: access denied (java.io.FilePermission
> /tmp read) at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java(
>Compiled Code))
>
>Now if I understand what's going on there, the servlet is falling over
>because it can't read /tmp...
>
>What I want to know is where this security policy is set?
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>