Thierry Carrez wrote: > Niels Thykier wrote: >> Thierry Carrez wrote: >>> 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]. > > The code doesn't use temporary files but a temporary directory. mkdir > being atomic, if /tmp/tomcat-temp can't be created because it already > exists, the code fails. There is no attack window, that's quite secure. > Dang, you are right. As long as we do not use "-p" we should be okay [1] - thanks for the clarification. >> On a related note; shouldn't the postrm script be removing the JVM_TMP >> dir rather than leaving it till next reboot? > > It could do that specifically on purge, but I don't think it /needs/ to. > If we do it using /tmp/tomcat-temp we are likely to trigger the previously mention lintian warning if we clean it in the postrm. I moved jetty's tmp dir to avoid that tag. I will revert to /tmp/tomcat-temp and leave /tmp/tomcat-temp be on purge, unless anyone else following this debate voices objections. ~Niels [1] 'atomic'ness aside, mkdir -p does not fail if the link points to an existing dir. In that case the script would change the owner of a given dir to tomcat6.
Attachment:
signature.asc
Description: OpenPGP digital signature