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
>
