Tomcat security configuration error prevents proper logging when used with Sun's JVM

I also installed a clean default installation of tomcat 5.5 on Ubuntu Server 8.0.4.3 LTS on 8/7/09. I was seeing the same exact behavior, plus webapp I deployed was not starting. I have come up with a workaround, but I do not recommend it for a production environment due to it's hammer approach. A better solution would be much appreciated.

1. Stop the Tomcat server
2. Add the following to /etc/tomcat5.5/policy.d/50user.policy

    grant {
                 permission java.security.AllPermission;
              };

3. Restart the Tomcat server
4. Check /var/log/tomcat55 and you'll see the logs

As you can see, this is a hammer approach to the permissions issue, but I was unable to determine which exact permissions needed to be opened in order to get logging to work.

What JVM are you using to run Tomcat5.5 on hardy ? Is Sun's JDK or OpenJDK installed ?
There is (at least) one known issue running Tomcat 5.5 under GCJ, see bug 251004.

I installed Sun's JDK 1.6.0_14-b08 via Ubuntu's apt-get utility. I do not have the GCJ installed. Please advise is there is any additional information or troubleshooting I can provide.

Also here Sun's JDK 1.6.0_14. On GCJ installed.

Confirmed when running tomcat5.5 with sun-java6: the securitymanager policy shipped by default apparently prevents logging from working correctly.

The recommended way of running tomcat5.5 is to run with openjdk-6 (universe) rather than the non-free sun-java6 (multiverse). Logging works correctly then.
Another possibility is to disable the Tomcat security manager (which is disabled by default in upstream distribution) by adding "TOMCAT5_SECURITY=no" to /etc/default/tomcat5.5

I got tomcat logging re-enabled using Sun's JDK without disabling Tomcat's security manager by adding this to /etc/tomcat5.5/policy.d/50user.policy:

grant {
    permission java.lang.RuntimePermission "setContextClassLoader";
};

It seems that openjdk does not implement all security checks as Sun's JDK does.

You may also put this in a file like /etc/tomcat6/policy.d/99custom-fixes.policy :

grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
 permission java.lang.RuntimePermission "setContextClassLoader";
};

... does the job without too widely opening security.

I'm having this problem on Jaunty also.

For what it's worth, you can apt-get install jsvc
and then use a simple init script to run apache.org tomcat
as tomcat user not root. We have been doing this for many
years to run tomcat and other custom java apps as
servers. A simple example jsvc init script is here:
http://staff.washington.edu/joshuadf/java/

Note that you will need to get tomcat security updates from
apache.org yourself.

To Joshua: The only (meaningful for this bug) difference running apache.org tomcat instead of the Ubuntu packages is that you don't get a security manager enabled by default, so you don't hit this bug and you don't have to care about configuring policy files. If you don't care about running with a security manager, I'd recommend running the Ubuntu package with TOMCAT5_SECURITY=no, you would get the same effect.

This bug is not about Ubuntu's tomcat packages, but rather with a recent change in Sun's JVM that make some changes in policy files required if you want to run with a security manager and Sun's JVM. This bug would hit both the apache.org prebuilt code and ours.

The right way of fixing this in packaging is to add

permission java.lang.RuntimePermission "setContextClassLoader";

in the grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" { ... } section of 03catalina.policy.

This bug was fixed in the package tomcat6 - 6.0.20-8ubuntu1

---------------
tomcat6 (6.0.20-8ubuntu1) lucid; urgency=low

  * Merge from Debian unstable. Remaining changes:
    - debian/control, debian/rules: Do not use 3.0 (quilt) source format yet
  * debian/tomcat6.default: Fix typos in "JSVC" and "remote", missing newline
  * debian/tomcat6.default, debian/tomcat6.init: Handle JSVC_CLASSPATH
    default value the same way as other defaults

tomcat6 (6.0.20-8) unstable; urgency=low

  * Corrected some spelling mistakes in debian/control.
    (Closes: #557377, #557378)
  * Added patches to install the OSGi metadata in some of the jars.
    (Closes: #558176)
  * Updated 03catalina.policy to allow "setContextClassLoader".
    - Fixes a problem where Sun's JVM would fail to generate log-files.
    (Closes: LP: #410379)
  * Updated /etc/default/tomcat6:
    - Clarified that JAVA_OPTS are passed to jscv and not the JVM.
    - Updated the JSP_COMPILER to javac (jikes is not in Debian anymore).
    (Closes: LP: #440685)
  * Use default-jdk and default-jre-headless instead of openjdk in
    (Build-)Depends.
  * Added more alternatives for java implementations to the Depends of
    libservlet2.5-java.
  * Exposed JSVC_CLASSPATH to the configuration file.
    (Closes: LP: #475457)
  * Updated description so it no longer refers to non-existent package.
    (Closes: #559475)
  * Used "set -e" in postinst and postrm instead of passing "-e" to sh
    in the #!-line.
  * Changed to 3.0 (quilt) source format.

tomcat6 (6.0.20-7) unstable; urgency=low

  * New patch fix_context_name.patch:
    - Allow Service name != Engine name. Regression in fix for 42707.
      Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47316
    - This has been fixed in trunk and will be in 6.0.21
  * Register libservlet2.5-java-doc API with doc-base
  * Fix short description of tomcat6-docs by using "documentation" suffix

tomcat6 (6.0.20-6) unstable; urgency=low

  [ Ludovic Claude ]
  * tomcat6.postinst: set the ownership of files in /etc/tomcat6/
    to root:tomcat6, to prevent an attacker running inside a tomcat6
    instance to change the tomcat configuration
  * debian/policy/02debian.policy: grant access to
    /usr/share/maven-repo/ as it is a valid source of Debian JARs.
    (Closes: #545674)
  * Bump up Standards-Version to 3.8.3
    - add debian/README.source that describes the quilt patch system.
  * debian/control: Add Conflicts on libtomcat6-java with old versions
    of tomcat6-common (Closes: #542397)

  [ Michael Koch ]
  * Replace dh_clean -k by dh_prep.
  * Added Ludovic and myself to Uploaders.
  * Build-Depends on debhelper >= 7.

tomcat6 (6.0.20-5) unstable; urgency=low

  * Fix jsp-api dependency in the Maven descriptors.
  * Put tomcat-juli.jar in /usr/share/java instead of juli.jar.
    This fixes a broken link which prevented tomcat to start
    when logging is turned on, and restores the file layout
    defined in 6.0.20-2.
  * Restore links to the jars in usr/share/tomcat6/lib
  * Change watch to download fresh sources from SVN.
    Should fix wrong encoding in tomcat-i18n-fr/es.jar in the next upstream
    version. (Closes: #522067)
  * Update ...