Thierry Carrez wrote: > Niels Thykier wrote: [...] > >> JVM_TMP issue >> ============= >> In Debian JVM_TMP was set to /tmp/tomcat6-tmp in the init script. I >> suspect this is also the case in Ubuntu (at least nothing suggests that >> it has been changed). >> >> I changed this to /var/cache/$NAME (defaults to /var/cache/tomcat6 >> [expanded before reading any config files])[3]. However I noticed that >> tomcat6's postrm script already deletes /var/cache/tomcat6; so should I >> change it to another value (and if so - which)? >> >> I also intend to change the default JVM_TMP value in >> debian/tomcat6.default (I did not notice it before my commit). > > Small explanation here... since I was the author of that tmp thing. For > (more) FHS compliance /var/lib/tomcat6/work (the tomcat6 compilation > cache directory) is a link to /var/cache/tomcat6. That's what this > directory is currently used for. It is also where the catalina.policy > combined file is being created when the init script starts. So it's > really used as a cache. This is different from the JVM temporary > directory (where temp files will be created by default), which should > definitely be separate (otherwise there is risk of conflict in files > being created there). > > I still think /tmp is the right location for JVM temp files, since they > aren't cache files and should be cleaned up at system restart. If you > don't want them to be in /tmp, you will have to use a specific directory > (separate from /var/cache/tomcat6) and make sure it's cleaned up > periodically. You mention a security problem as the main reason to > change that, could you elaborate ? This code looks secure to me. > I based on a certain lintian tag[1] and the "symlink race"[2] - I admit I am not sure to what extend someone could use the attack; the attack window is very short as I understand it and does require local user access[3]. On a related note; shouldn't the postrm script be removing the JVM_TMP dir rather than leaving it till next reboot? I am considering to use /var/cache/libtomcat6-java/ or /var/cache/tomcat6-tmp/ as tmp dir. I assume that periodically means "on restart of tomcat6" (because this is what we have now[4]) and then also in the postrm script (since unlike /tmp the new dir will not be removed by itself). >> (Build-)Depends - The remaining delta >> ===================================== >> I have committed all of these changes except for the "java5-runtime-headless as alternative for tomcat6". I am considering to leave it at this - especially if this means that Ubuntu will not have to change the package. >> ** Ubuntu ** >> Bugs from Ubuntu I believe will be or could be easily fixed and that I >> am considering to get into the next Debian upload. >> >> LP: #375493: tomcat6 needs debug start mode with jpda >> As promised Ludovic Claude added the change stated in comment#4. Thierry >> - are you satisfied with the solution? If so - this bug can be closed >> with a sync from Debian (though it is not mention in the changelog as a >> bug closing change). > > Sure, sounds good. > Added a changelog entry in the -5 revision that will close the bug on the Ubuntu side (assuming that all revisions after the latest revision in Ubuntu are parsed). >> LP: #475457: Adding JSVC_CLASSPATH to /etc/default/tomcat6 >> I understand this is being working on and I see no reason not to include >> the solution in Debian as well. > > If everyone agrees, I can commit that change to Debian SVN rather than > Ubuntu and sync the resulting debian package (when published) in Ubuntu. > If anyone wants to have a stab at it before I can commit time to do > that, please be my guest. > I would not mind if you committed it directly to the Debian SVN. I have not looked at fixing this one at all. I may, but will not promise to, take a jab at it in this weekend. >> LP: #440685: Make it clearer that JAVA_OPTS is about JSVC options >> Assuming this is just debian/tomcat6.default that needs the update; this >> seems trivial to fix and I do not mind doing it. > > Yes, it's just about making the comment a little more obvious to avoid > further bugs like this one. > Committed. >> LP: #410379: Tomcat security configuration error prevents proper ... >> As I understand it; the solution appears to be granting permission to do >> setContextClassLoader and openjdk6 is only unaffected because it lacks >> some implementation on the SecurityManager area. However I am unsure >> which policy file to add it to. > > I just commented on the bug on the right way to fix this. Note that this > is only needed to support Sun's JVM at the moment. However, it shouldn't > hurt openJDK and future releases of OpenJDK might be affected when they > catch up, so it sounds like a reasonable fix. > Committed as well. As for the bugs on the Debian side; I will carry out my "intends" on Sunday if I do not hear anything about them and no one asks for a extension to research the problem. For the bugs that I have not stated an action; I will ping the submitter and ask if they can still reproduce the problem with tomcat6. ~Niels [1] possibly-insecure-handling-of-tmp-files-in-maintainer-script [2] http://en.wikipedia.org/wiki/Symlink_race [3] Particularly; I do not know any serious server admin allowing users on their web-servers if they can avoid it. [4] At least to my knowledge files are not removed in /tmp/ periodically. Then again - I usually do not monitor the live-time of stuff in /tmp.
Attachment:
signature.asc
Description: OpenPGP digital signature