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.britt...@mulesource.com> Sujet: Re: Tomcat packaging improvements Pour :: Thierry Carrez <thierry.car...@ubuntu.com> Copie à :: Ludovic Claude <ludovic.claud...@googlemail.com>, Torsten Werner <mail.twer...@googlemail.com>, Niels Thykier <ni...@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.car...@ubuntu.com <mailto:thierry.car...@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 -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
