[Fwd: Re: Tomcat packaging improvements]
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.
Ludovic
-------- Message original --------
De: Jason Brittain <jason.brittain@mulesource.com>
Sujet: Re: Tomcat packaging improvements
Pour :: Thierry Carrez <thierry.carrez@ubuntu.com>
Copie à :: Ludovic Claude <ludovic.claude54@googlemail.com>, Torsten
Werner <mail.twerner@googlemail.com>, Niels Thykier <niels@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
discuss:
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
anything.
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?
Thanks.
--
Jason
On Thu, Feb 11, 2010 at 2:15 AM, Thierry Carrez
<thierry.carrez@ubuntu.com <mailto:thierry.carrez@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
http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html
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
Reply to: