On 24/09/2009 15:19, Alan wrote:
Well, I'll try to make it clearer:

Situation: Ubuntu 9.04 with SUN Java 1.6 and tomcat 5.5.26 with
security mode (default in Debian/Ubuntu).

Testing tomcat-webapps examples.

A clean install and everything seems to work, except that nothing is
written in /var/log/tomcat5.5

To solve this issue, I had to add:

permission java.lang.RuntimePermission "setContextClassLoader";

in /etc/tomcat5.5/policy.d/03catalina.policy.

If using openJDK instead of Sun Java, this is not necessary.

The patch I sent before is for those using tomcat5.5.26 in Mac OSX and
Fink use this distribution.

Did it help?

You seemed to be suggesting that there were multiple problems, or was that a figure of speech? Faint alarm bells were ringing...

p





Alan

On Thu, Sep 24, 2009 at 14:57, Pid<p...@pidster.com>  wrote:
On 24/09/2009 14:11, Alan wrote:

Hallelujah!

I finally figured out what's going on with tomcat 5.5.26 when running
webapps in security mode.

In Ubuntu 9.04, with just the addition of 'permission
java.lang.RuntimePermission "setContextClassLoader";' in
catalina.policy solved the problem. This is happen because ubuntu has
its own way of starting the deamon and apparently they fixed some
problems that in tomcat 5.5.26 official distribution is not.

Really?  Could you let us know what?

p


Since Fink also use the official distribution, I found out that I need
to tweak catalina.policy a bit further there. See the patch:

--- catalina.policy     2009-09-24 13:51:41.000000000 +0100
+++ /Users/alan/SCRIPTS/catalina.policy 2009-09-24 13:50:24.000000000
+0100
@@ -66,7 +66,7 @@
  };

  // These permissions apply to the commons-logging API
-grant codeBase "file:${catalina.home}/bin/commons-logging-api.jar" {
+grant codeBase "file:${catalina.home}/bin/commons-logging-api-1.1.1.jar"
{
          permission java.security.AllPermission;
  };

@@ -82,6 +82,7 @@

  // These permissions apply to JULI
  grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
+        permission java.lang.RuntimePermission "setContextClassLoader";
          permission java.util.PropertyPermission
"java.util.logging.config.class", "read";
          permission java.util.PropertyPermission
"java.util.logging.config.file", "read";
          permission java.lang.RuntimePermission "shutdownHooks";
@@ -95,6 +96,8 @@
          // Be sure that the logging configuration is secure before
enabling such access
          // eg for the examples web application:
          // permission java.io.FilePermission

"${catalina.base}${file.separator}webapps${file.separator}examples${file.separator}WEB-INF${file.separator}classes${file.separator}logging.properties",
"read";
+        permission java.io.FilePermission

"${catalina.base}${file.separator}webapps${file.separator}jsp-examples${file.separator}WEB-INF${file.separator}classes${file.separator}logging.properties",
"read";
+        permission java.io.FilePermission

"${catalina.base}${file.separator}webapps${file.separator}servlets-examples${file.separator}WEB-INF${file.separator}classes${file.separator}logging.properties",
"read";
  };

  // These permissions apply to the servlet API classes


This basic solved my problems.

Alan

On Wed, Sep 23, 2009 at 22:58, Alan<alanwil...@gmail.com>    wrote:

Many thanks dear Mark.

It's late here too but I finally, with your diligent and precious
help, I could figure out what's going on here and even manage to have
tomcat with security working for tomcat6.0.20 and tomcat5.5.28 (but
not for tomcat5.5.26, last version available for Mac via Fink).

Thank you very much.

Alan

On Wed, Sep 23, 2009 at 21:42, Mark Thomas<ma...@apache.org>    wrote:

Mark Thomas wrote:

Mark Thomas wrote:

Alan wrote:

Thanks Mark, let's deal by parts:

OK. I've reproduced it. It is happening with 1.6.0_14 and 1.6.0_16
JVMs
but not a 1.6.0_00 JVM.

The latest 1.5 JVM seems OK too.

Time to check the release notes. I'll hopefully have a workaround
(other
than using Java 1.5) shortly.

Still not clear why it is required for later JVM versions

<snip/>

It is late and I have been in front my PC for too long today. This has
already been fixed (by me!) in trunk and proposed for 6.0.x and 5.5.x.
It looks the implementation of LogManager (ClassLoaderLogManager extends
LogManager) has changed - hence the need for the new permission.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to