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

Bug #410379 reported by dukat on 2009-08-07
This bug affects 6 people
Affects Status Importance Assigned to Milestone
tomcat5.5 (Ubuntu)
tomcat6 (Ubuntu)
Thierry Carrez

Bug Description

Ubuntu Server 8.04.3 LTS
tomcat5.5, 5.5.25-5ubuntu1.2

Tomcat's logging facility does not work in a clean default installation: No logfiles at all are generated in /var/log/tomcat5.5, even if severe errors occur in Tomcat.

The problem seems to be a permission error. Looking at syslog, I can see at startup:
  18:31:33 hikuku jsvc.exec[25015]: Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
Aug 7 18:31:33 hikuku jsvc.exec[25015]: access denied (java.lang.RuntimePermission setContextClassLoader)

Afterwards the syslog is clogged completely with "Can't load log handler """ entries all over.

I guess it's a problem with the catalina.policy file, but I have no idea how to fix this.

Please don't tell me to upgrade to a newer Ubuntu version, for my server I need LTS...

dukat (dukat) wrote :
DawnH (dawnh) wrote :

I also installed a clean default installation of tomcat 5.5 on Ubuntu Server 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 {

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.

Thierry Carrez (ttx) wrote :

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.

Changed in tomcat5.5 (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
DawnH (dawnh) wrote :

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.

dukat (dukat) wrote :

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

Changed in tomcat5.5 (Ubuntu):
status: Incomplete → New
Thierry Carrez (ttx) wrote :

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

Changed in tomcat5.5 (Ubuntu):
importance: Medium → Low
status: New → Confirmed
summary: - Tomcat security configuration error prevents proper logging
+ Tomcat security configuration error prevents proper logging when used
+ with Sun's JVM
dukat (dukat) wrote :

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.

Thierry Carrez (ttx) on 2009-08-18
Changed in tomcat5.5 (Ubuntu):
status: Confirmed → Triaged
Thierry Carrez (ttx) on 2009-09-24
Changed in tomcat6 (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Régis Desgroppes (rdesgroppes) wrote :

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.

Brazen (jdinkel) wrote :

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 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:

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

Thierry Carrez (ttx) wrote :

To Joshua: The only (meaningful for this bug) difference running 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 prebuilt code and ours.

Thierry Carrez (ttx) wrote :

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.

Thierry Carrez (ttx) on 2009-12-14
Changed in tomcat6 (Ubuntu):
assignee: nobody → Thierry Carrez (ttx)
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :
Download full text (4.2 KiB)

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
  * Added more alternatives for java implementations to the Depends of
  * 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.
    - 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 ...


Changed in tomcat6 (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.