tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Tomcat6 - access denied exception ONE TIME after each restart, then all ok... Why? & How to make it stop?
Date Sun, 01 Nov 2009 00:29:53 GMT

"Pete McNeil" <> wrote in message
> Christopher Schultz wrote:
>> Hash: SHA1
>> Pete,
>> On 10/30/2009 7:59 PM, Pete McNeil wrote:
>>> Fresh install of Tomcat6 on fresh install of ubuntu.
>> Be specific: exactly which version of Tomcat 6?
> Using CATALINA_BASE:   /usr/share/tomcat6
> Using CATALINA_HOME:   /usr/share/tomcat6
> Using CATALINA_TMPDIR: /usr/share/tomcat6/temp
> Using JRE_HOME:       /usr
> Server version: Apache Tomcat/6.0.18
> Server built:   Feb 27 2009 06:50:18
> Server number:
> OS Name:        Linux
> OS Version:     2.6.24-24-xen
> Architecture:   amd64
> JVM Version:    1.6.0_0-b14
> JVM Vendor:     Sun Microsystems Inc.

>From the code, it looks like it should work in this version (at least with 
the standard Tomcat distro). But it is possible that it was fixed in 6.0.19 
(it's too long ago to remember the change log entry there, and I don't feel 
like researching).

>>>      <Host name="someplace" appBase="/home/someplace/webapps"
>>>            unpackWARs="true" autoDeploy="true"
>>>            xmlValidation="false" xmlNamespaceAware="false">
>>>            <Context
>>>              path=""
>>>              docBase="/home/someplace/"
>>>              reloadable="true"/>
>> NB: <Context> should be in a context.xml file on the disk, not in your
>> server.xml file.
> Tried that -- couldn't make it work. I want this to be the default 
> application on this server and I want to host it from a specific user 
> directory. This seems to be the recommended way to do that, and it works.
> <snip/>
>> First access after what? Tomcat restart? Webapp restart?
> Thought I was clear on that, sorry. First request after restarting tomcat.
> <snip/>
>> That's interesting that this exception happens only once, given that
>> each time it should attempt to load the same class.
>> Given the exception, I suspect it's an incorrectly-configured
>> SecurityManager.
> <snip/>

It gets to try again when generating the error page (at which point only 
trusted Tomcat code is on the stack).

> I have seen suggestions that this might be some kind of timing issue with 
> the security manager.
> I've also received the following suggestion directly (off list):
> $CATALINA_HOME/conf/catalina.policy
> grant codeBase "file:${catalina.home}/lib/tomcat-coyote.jar" {
> {
>    //set coyote perms
>    permission java.lang.RuntimePermission 
> "*";
> }

In the default policy files, it should already have AllPermision.  So this 
should do nothing.

> ===
> In the mean time I was trying to solve something else and stumbled upon 
> fixing this issue at the same time... However I don't pretend to 
> completely understand it and I'm sure the underlying issue isn't resolved 
> since it wasn't really addressed. I will dig deeper tomorrow and try to 
> find the answer. I hope also that this thread will eventually show the 
> answer for others to find.
> My temporary solution was to add the following to 
> /etc/tomcat6/policy.d/50local.policy
> grant codeBase "file:/home/someplace/" {
>        permission;
> };
> ----
> I am porting this app from a different resin based server to a new tomcat 
> based server. My previous server did not have a security manager. The 
> other problem I was attempting to solve was a security issue where a tool 
> we built in a .jar was not able to connect to one of our servers. I tried 
> to grant specific permissions for that jar - - and the result was nothing 
> would work...
> I finally granted all permissions (I know this is heavy handed) to the 
> app's root and not only did it solve my server access problem, but the 
> problem that started this thread also went away. Now that I have this in 
> place the first request after a tomcat restart does not create an error.

Or just edit the startup script to run without a SecurityManager.

> ----
> I read that a grant read entry is created automatically for any app that 
> is deployed.
> I read in other places that this kind of thing might be a timing issue.
> I wonder if the error occurred because the automatically generated grant 
> read entry was not in place for the first request after a tomcat restart; 
> and that my heavy-handed grant for the entire app has "hidden" this 
> problem because my entry is always in place as tomcat comes up.
> Those are my thoughts.
> I look forward to eliminating the mystery and finding the correct solution 
> (even if what I have now seems to work).

It's trying to load a Tomcat internal class (ironically a PrivilegedAction), 
and the default policy file doesn't allow access to Tomcat internal classes 
from untrusted code.  Tomcat is supposed to load that class at startup (at 
which point it can be used in untrusted code).  Since hitting any servlet 
that calls flush first should trigger this, anybody with too much time on 
their hands can test it ;).

> Best,
> _M 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message