Fwd: Re: Tomcat packaging improvements

Ludovic Claude ludovic.claude54 at googlemail.com
Fri Feb 12 20:35:19 GMT 2010

Jason, I will fix point 2.
About 1., I have seen those classloaders directories being used by some
applications, in particular Alfresco from Ubuntu partner repository, so
changing this may break existing stuff.
About 3. I will have a look, but I'm not sure if I can make it work and
test it properly.

Forwarding your comments to the mailing lists for broader comments and
maybe help.


-------- Message original --------
De: 	Jason Brittain <jason.brittain at mulesource.com>
Sujet: 	Re: Tomcat packaging improvements
Pour :: 	Thierry Carrez <thierry.carrez at ubuntu.com>
Copie à :: 	Ludovic Claude <ludovic.claude54 at googlemail.com>, Torsten
Werner <mail.twerner at googlemail.com>, Niels Thykier <niels at thykier.net>

This all sounds good to me.  Out of the box, Tomcat is pretty
secure.  Tomcat itself doesn't need the security manager enabled
in order to operate securely -- user's webapps might, but Tomcat
doesn't know which ones those are.  A person has to make that
judgement.  I tend to tell users that they should assume that the
webapps their company writes are insecure, but that malicious
successful exploits are rare, and that it tends to be very
difficult to exploit servlet webapps.  Most developers and ops
Tomcat users sleep just fine at night knowing that their webapp
is available on the public Internet, and the security manager is
not enabled.

Torsten: Your idea to use debconf to decide whether Tomcat starts
automatically sounds like the best solution.  Thanks.

Ludovic: I had a look at the docs you added, and they look great.

I had a few more topics I wanted to ask you guys about.  These
are things that do not need to change for Lucid, if we don't have
time, or if we don't want to.  I just wanted to bring them up to

1. I noticed that the way we have tomcat6 configured is to add
   back the classloader directories that were present in Tomcat
   versions 4 and 5: shared/, common/, and server/.  Stock Tomcat
   6 got rid of these as of 6.0.0.  Some software is still
   written for Tomcat 5.5, and docs may still refer to these
   classloading dirs..  I always found them helpful, since
   Tomcat's classloader hierarchy still has these three
   classloaders (server, common, and shared), but by default
   Tomcat 6 was always configured to just load everything from
   CATALINA_BASE/lib/.  Being informed about Tomcat, I can handle
   these dirs being present, but this will likely confuse some
   users because stock Tomcat 6 doesn't have them.  Looking
   forward to Tomcat 7, they're not being reintroduced, either.
   What do you think about eliminating these directories to make
   the Debian tomcat6 package more like stock Tomcat 6?

2. One question about the Maven poms: If quilt pulls Tomcat
   source from Subversion, and if Tomcat 6 source comes with
   Maven poms (see res/maven/), then why does the Debian source
   tree also include Tomcat poms?  Am I missing something?  I
   have looked at what the diffs may be, and I didn't find

3. When the init script invoked Tomcat via jsvc, it had to be run
   by an administrator user because jsvc itself had to be started
   as root in order to allow binding to privileged ports.  Now
   that we use authbind, it doesn't require the init script to
   run as an administrator to do the same thing.  For example the
   init script could run as user 'tomcat6' and starts, stops, and
   restarts could work just fine while Tomcat could still bind to
   privileged ports.  So, what's the use case for the init script
   being run as user 'tomcat6'?  There are situations where the
   administrator does not want to or cannot configure sudo for a
   user to be able to run the Tomcat init script, or where there
   is a script that runs as user tomcat6 that needs to be able to
   either restart Tomcat or get Tomcat's status.  It is possible
   to make this work now that the init script doesn't use jsvc,
   and I thought I'd ask you whether you think it would be
   helpful to allow it.  The code change would be only inside the
   init script -- it would be a relatively small change to remove
   the few lines of code that requires the user be root to run
   it, possibly invoke start-stop-daemon without the --user
   switch, maybe a small number of changes to make sure that
   running the rest of the init script as non-root works
   properly.  I think the changes are pretty small.  It would,
   however, need to be tested afterwards to make sure the usual
   use case works properly still.  So, I'm not proposing making
   this change for Lucid, unless there's time in the schedule to
   test and debug it afterwards.  What do you guys think?


On Thu, Feb 11, 2010 at 2:15 AM, Thierry Carrez
<thierry.carrez at ubuntu.com <mailto:thierry.carrez at ubuntu.com>> wrote:

    Ludovic Claude wrote:
    > I have committed the additional documentation, if nobody objects
    to the
    > changes or find any issue in the package then I will release it this
    > week-end.

    I had a look at the diff, and it looks very reasonable to me.

    Minor remark about the README:

    > * Tomcat is NOT secured by default. Before exposing your Tomcat
    > instance to the internet, please change the passwords in
    > /etc/tomcat6/tomcat-users.xml and turn on Java security: edit your
    > /etc/default/tomcat6 file and set TOMCAT6_SECURITY="yes".
    > After you may need to change the policy files in
    > /etc/tomcat6/policy.d/

    This sounds slightly too worrying to me. Especially since
    tomcat-users.xml is secure by default (user/roles/passwords are
    commented, so no user is defined !). I'd suggest changing this to:

    * Tomcat is not running under a Java security manager by default. If you
    expose your Tomcat instance to the internet, please consider editing
    your /etc/default/tomcat6 file and set TOMCAT6_SECURITY="yes", then
    adjust policy files in /etc/tomcat6/policy.d/ as explained in

    Uploading over the week-end is perfect, I'll be able to make sure it
    syncs in Ubuntu before Lucid FeatureFreeze (next Thursday).

    Thierry Carrez
    Ubuntu server team

More information about the Ubuntu-java mailing list