You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ed Gomolka <eg...@gyldan.com> on 2001/04/17 22:59:36 UTC
Security Manager/tomcat.policy Problems
Platform: Linux Mandrake 7.2/Apache 1.3-19/Tomcat 3.2.1
Can somebody clarify a security manager issue for me?
We have an application that allows the user to upload GIF/JPEG images.
This has worked fine in development, but has stopped working since we
started tightening up security
in the tomcat.policy file. Maybe somebody can tell me what I'm doing wrong.
We've been starting up Tomcat with the security option for several months,
but have had the permissions
wide open in development, as shown here by our old entry in the
tomcat.policy file.
grant
{
permission java.security.AllPermission;
};
The above entry provides us with no security protection, so we'd like to
tighten it up;
however, we have run into problems. Before we write the
image file on the server, we check the validity of the path with the
"File.exists()" method, and
we verify that we have write access by using the "File.canWrite()" method.
These two methods generate exceptions. Here's the one for the canWrite()
method:
java.security.AccessControlException: access denied (java.io.FilePermission
/var/tomcat/webapps/edg/pictures/covers/upload/44KB.gif write)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:978)
at java.io.FileOutputStream.<init>(FileOutputStream.java:96)
at java.io.FileOutputStream.<init>(FileOutputStream.java:62)
at java.io.FileOutputStream.<init>(FileOutputStream.java:132)
at
com.ais.util.servlet.MultipartFormInputReader.readAndSaveFile(MultipartFormInputReader.java:417)
at
com.ais.util.servlet.MultipartFormInputReader.readNextPart(MultipartFormInputReader.java:251)
at
com.ais.util.servlet.MultipartFormInputReader.getAttachments(MultipartFormInputReader.java:163)
at
com.ais.util.servlet.ServletEngine.handleForm(ServletEngine.java:1060)
at com.ais.util.servlet.ServletEngine.doPost(ServletEngine.java:542)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java)
at org.apache.tomcat.core.Handler.service(Handler.java)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java)
at
org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java)
at java.lang.Thread.run(Thread.java:484)
According to the Javadoc for the JDK, these methods should be able to work
under a security manager just fine.
Indeed, the fact that they were working under the old tomcat.policy entry
tells me that they react to security manager
policy changes.
If we suppress the use of the File.exists() and File.canWrite() methods,
the image files get uploaded and written out just fine.
It makes no sense to me that the methods should fail, if the images can be
written.
Here's the new tomcat.policy entry:
grant codeBase "file:${tomcat.home}/webapps/edg/-"
{
permission java.net.SocketPermission "localhost:1024-","listen";
//grant permission to read all properties
permission java.util.PropertyPermission "*","read";
//grant permission to read/write/delete images
permission java.io.FilePermission
"${tomcat.home}/webapps/edg/pictures/covers/upload/*","read,write,delete";
};
Any ideas?
Ed
RE: Security Manager/tomcat.policy Problems
Posted by Ed Gomolka <eg...@gyldan.com>.
At 02:02 PM 4/17/01 -0700, you wrote:
>the user who owns the Tomcat process doesn't have the OS permission for the
>file
>
>this can be fixed using the "chmod" command
>
>Filip
Thanks for the suggestion. That would be the logical first thing to check,
and I've certainly made
my share of mistakes of that sort in the past, but that's not the
issue in this case, for the following reasons:
1) Tomcat was started via the sudo command, and has root permissions
2) I also get a read exception in another place, yet the files/directories
are globally readable
3) The whole problem goes away when the permissions in the tomcat.policy
file are thrown wide open as follows:
grant
{
permission java.security.AllPermission;
};
There's probably something very basic that's set up wrong, but I'm not
seeing it.
Ed
Re: Security Manager/tomcat.policy Problems
Posted by Ed Gomolka <eg...@gyldan.com>.
I've figured out the solution to my problem, so I'm replaying to my own
message on the off
chance that anyone's interested in the solution.
There was a mismatch between the way that I had the permissions set in
the security manager, and the way that the Java code was verifying permissions.
I had permissions set on the directory as follows:
permission java.io.FilePermission
"${tomcat.home}/webapps/edg/pictures/covers/upload/*","read,write,delete";
That gave me read,write,delete permissions on any file in the directory.
I checked the write permissions as follows:
File uploadDirFile = new File(uploadDirectory);
if (!uploadDirFile.canWrite())
{
throw new ServletRuntimeException("Not writable: " +
uploadDirectory);
}
The canWrite() method generated an exception rather than a true/false boolean.
The problem was that the code was checking whether the directory itself was
writable, but the permission statement only gave me
access to whatever was inside the directory.
In order to make things work, I will have to either modify the code
somewhat, or expand the permissions in the tomcat.policy
file by adding a second line, as follows:
permission java.io.FilePermission
"${tomcat.home}/webapps/edg/pictures/covers/upload/","read,write";
permission java.io.FilePermission
"${tomcat.home}/webapps/edg/pictures/covers/upload/*","read,write,delete";
The first line gives read/write permissions to the directory itself, and
the second line gives read/write/delete permissions to all
files within the directory.
Ed
At 03:59 PM 4/17/01 -0500, you wrote:
>Platform: Linux Mandrake 7.2/Apache 1.3-19/Tomcat 3.2.1
>
>Can somebody clarify a security manager issue for me?
>
>We have an application that allows the user to upload GIF/JPEG images.
>This has worked fine in development, but has stopped working since we
>started tightening up security
>in the tomcat.policy file. Maybe somebody can tell me what I'm doing wrong.
>
>
>We've been starting up Tomcat with the security option for several months,
>but have had the permissions
>wide open in development, as shown here by our old entry in the
>tomcat.policy file.
>
>grant
>{
> permission java.security.AllPermission;
>};
>
>The above entry provides us with no security protection, so we'd like to
>tighten it up;
>however, we have run into problems. Before we write the
>image file on the server, we check the validity of the path with the
>"File.exists()" method, and
>we verify that we have write access by using the "File.canWrite()" method.
>These two methods generate exceptions. Here's the one for the canWrite()
>method:
>
>
>java.security.AccessControlException: access denied
>(java.io.FilePermission
>/var/tomcat/webapps/edg/pictures/covers/upload/44KB.gif write)
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
> at
> java.security.AccessController.checkPermission(AccessController.java:399)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
> at java.lang.SecurityManager.checkWrite(SecurityManager.java:978)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:96)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:62)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:132)
> at
> com.ais.util.servlet.MultipartFormInputReader.readAndSaveFile(MultipartFormInputReader.java:417)
> at
> com.ais.util.servlet.MultipartFormInputReader.readNextPart(MultipartFormInputReader.java:251)
> at
> com.ais.util.servlet.MultipartFormInputReader.getAttachments(MultipartFormInputReader.java:163)
> at
> com.ais.util.servlet.ServletEngine.handleForm(ServletEngine.java:1060)
> at com.ais.util.servlet.ServletEngine.doPost(ServletEngine.java:542)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java)
> at
> org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java)
> at org.apache.tomcat.core.Handler.service(Handler.java)
> at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java)
> at
> org.apache.tomcat.core.ContextManager.internalService(ContextManager.java)
> at org.apache.tomcat.core.ContextManager.service(ContextManager.java)
> at
> org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java)
> at
> org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java)
> at
> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java)
> at java.lang.Thread.run(Thread.java:484)
>
>According to the Javadoc for the JDK, these methods should be able to work
>under a security manager just fine.
>Indeed, the fact that they were working under the old tomcat.policy entry
>tells me that they react to security manager
>policy changes.
>If we suppress the use of the File.exists() and File.canWrite() methods,
>the image files get uploaded and written out just fine.
>It makes no sense to me that the methods should fail, if the images can be
>written.
>Here's the new tomcat.policy entry:
>
>grant codeBase "file:${tomcat.home}/webapps/edg/-"
>{
> permission java.net.SocketPermission "localhost:1024-","listen";
> //grant permission to read all properties
> permission java.util.PropertyPermission "*","read";
> //grant permission to read/write/delete images
> permission java.io.FilePermission
> "${tomcat.home}/webapps/edg/pictures/covers/upload/*","read,write,delete";
>};
>
>Any ideas?
>
>Ed
>
RE: Security Manager/tomcat.policy Problems
Posted by Filip Hanik <ma...@filip.net>.
the user who owns the Tomcat process doesn't have the OS permission for the
file
this can be fixed using the "chmod" command
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
filip@filip.net
www.filip.net