Trouble letting a Tomcat5 webapp write to a directory.
Adam Funk
1.4.2_07 SDK. I'm trying to let a web application write to a subdirectory
(appropriately named "data/output/" of its own WEB-INF directory.
I've added the following stanza to the catalina.policy file:
grant codeBase "file:${catalina.home}/webapps/cafetiere/WEB-INF/-" {
permission java.io.FilePermission
"file${catalina.home}/webapps/cafetiere/WEB-INF/data/output/-",
"read,write,execute";
};
(Actually I've added it to a file in /etc/tomcat5/policy.d/ which, I've
checked, is getting correctly concatenated into the catalina.policy file.)
But I'm still getting the following exception in the log:
java.security.AccessControlException: access denied
(java.io.FilePermission /var/lib/tomcat5/webapps/cafetiere/WEB-INF/data/output/output-11
32577981141-9650.xml write)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at
java.security.AccessController.checkPermission(AccessController.java:401)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:954)
at java.io.FileOutputStream.<init>(FileOutputStream.java:169)
at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
at java.io.FileWriter.<init>(FileWriter.java:73)
at uk.ac.nactem.reader.XMLReader.writeFile(XMLReader.java:186)
at
uk.ac.nactem.workflow.WebWorkflow2.storeOutput(WebWorkflow2.java:236)
at uk.ac.nactem.workflow.WebWorkflow2.webRun(WebWorkflow2.java:257)
...
Any ideas what I'm doing wrong?
Thanks,
Adam
HalcyonWild
Adam Funk wrote:
> I'm using the Debian tomcat5 package (version 5.0.30-7) and the Sun Java
> 1.4.2_07 SDK. I'm trying to let a web application write to a subdirectory
> (appropriately named "data/output/" of its own WEB-INF directory.
>
> I've added the following stanza to the catalina.policy file:
>
> grant codeBase "file:${catalina.home}/webapps/cafetiere/WEB-INF/-" {
> permission java.io.FilePermission
> "file${catalina.home}/webapps/cafetiere/WEB-INF/data/output/-",
> "read,write,execute";
> };
>
>
I dont really know about catalina.policy. But did you try chmod 777 on
the data/output folder.
Nigel Wade
My initial guess would be filesystem permissions. No Java policy can override
the actual permissions on the files/directories themselves.
Which user does Tomcat run as? On my system (running Tomcat4) it's the userid
tomcat4. Make sure that user has permission from the OS to open/write the file
in question.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : n...@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
Adam Funk
> My initial guess would be filesystem permissions. No Java policy can
> override the actual permissions on the files/directories themselves.
>
> Which user does Tomcat run as? On my system (running Tomcat4) it's the
> userid tomcat4. Make sure that user has permission from the OS to
> open/write the file in question.
On this system, Tomcat runs as user tomcat5, which belongs only to nogroup.
Everything under tomcat5/webapps/ is owned by tomcat5.nogroup and has
permissions "-rw-r--r--" (the directories are "drwxr-xr-x").
William Brogden
> Adam Funk wrote:
>
>> I'm using the Debian tomcat5 package (version 5.0.30-7) and the Sun Java
>> 1.4.2_07 SDK. I'm trying to let a web application write to a
>> subdirectory
>> (appropriately named "data/output/" of its own WEB-INF directory.
>>
>> I've added the following stanza to the catalina.policy file:
>>
>> grant codeBase "file:${catalina.home}/webapps/cafetiere/WEB-INF/-" {
>> permission java.io.FilePermission
>> "file${catalina.home}/webapps/cafetiere/WEB-INF/data/output/-",
^
shouldnt that be "file:${catalina.home} in the line above?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Adam Funk
> On Tue, 22 Nov 2005 10:04:20 +0000, Nigel Wade <n...@ion.le.ac.uk> wrote:
>
>> Adam Funk wrote:
>>
>>> I'm using the Debian tomcat5 package (version 5.0.30-7) and the Sun Java
>>> 1.4.2_07 SDK. I'm trying to let a web application write to a
>>> subdirectory
>>> (appropriately named "data/output/" of its own WEB-INF directory.
>>>
>>> I've added the following stanza to the catalina.policy file:
>>>
>>> grant codeBase "file:${catalina.home}/webapps/cafetiere/WEB-INF/-" {
>>> permission java.io.FilePermission
>>> "file${catalina.home}/webapps/cafetiere/WEB-INF/data/output/-",
> ^
> shouldnt that be "file:${catalina.home} in the line above?
Yes, and it is in my file and original post. The : must have been lost in
the reply-quoting.
Adam Funk
>> Which user does Tomcat run as? On my system (running Tomcat4) it's the
>> userid tomcat4. Make sure that user has permission from the OS to
>> open/write the file in question.
>
> On this system, Tomcat runs as user tomcat5, which belongs only to
> nogroup.
>
> Everything under tomcat5/webapps/ is owned by tomcat5.nogroup and has
> permissions "-rw-r--r--" (the directories are "drwxr-xr-x").
Further to this, I've checked that user tomcat5 can create files in the
output directory.
$ cd /var/lib/tomcat5/webapps/cafetiere/WEB-INF/data/output
$ touch foo
touch: cannot touch `foo': Permission denied
$ su
Password:
# touch root
# sudo -u tomcat5 touch t5
# ls -l
total 0
-rw-r--r-- 1 root root 0 2005-11-22 15:31 root
-rw-r--r-- 1 tomcat5 nogroup 0 2005-11-22 15:31 t5
Richard Scott Smith
I don't use Debian (I use Slackware), but this looks like Tomcat is
possibly running under a username that doesn't have permissions to write
to that directory (/$CATALINA_HOME/webapps/whatever) or there is a file
owned by another user in that directory which the username tomcat is
running under cannot overwrite. This can happen when Tomcat is started
while running under a startup scripts as root then it is stopped and later
started under a normal user like from within a plugin while doing
development, ie Tomcat is now running under YOU and can't overwrite files
created from root: log files, work files from JSP compilations, etc.
Hope this helps,
R. Scott Smith
PS: I was having trouble (with my news client) replying yesterday. Forgive
me if this repeats someone else's or even my own suggestions.
Adam Funk
> I don't use Debian (I use Slackware), but this looks like Tomcat is
> possibly running under a username that doesn't have permissions to write
> to that directory (/$CATALINA_HOME/webapps/whatever) or there is a file
> owned by another user in that directory which the username tomcat is
> running under cannot overwrite. This can happen when Tomcat is started
> while running under a startup scripts as root then it is stopped and later
> started under a normal user like from within a plugin while doing
> development, ie Tomcat is now running under YOU and can't overwrite files
> created from root: log files, work files from JSP compilations, etc.
I'm almost sure that it runs as tomcat5:nogroup, which is also the ownership
of everything under $CATALINA_HOME. But to be sure, I just changed the
permissions on webapps/cafetiere/WEB-INF/data/output to 777 and ran it
again and STILL got the same exception.
java.security.AccessControlException: access denied (java.io.FilePermission
/var/lib/tomcat5/webapps/cafetiere/WEB-INF/data/output/output-1132745107191-1859.xml
write)
Richard Scott Smith
One thing that got me one time was that the owner of log files in
$CATALINA_HOME/logs was root because I had run tomcat as root one time.
Other directories can be affected too. Trying to run Tomcat as another
user didn't work because root had written some other files.
Maybe try running these two commands: chown -R
tomcat5:nogroup $CATALINA_HOME
chmod -R u+w $CATALINA_HOME
Running these commands will ensure there are no loose files that don't
have the same permissions. Hopefully someone's suggestion will get you
going.
--
R. Scott Smith
Slackware Linux on the job, at home, everywhere!
Nigel Wade
Does the file you are trying to write to already exist, without write
permission?
I've never used policies to grant write permission for Tomcat, so I don't know
what's necessary. I don't remember having to do anything in Tomcat4 to get a
servlet to write to a directory in the filesystem to which the user tomcat4 had
permission. Maybe Tomcat5 has tightened up security and file access.