imapd rpm -q imap imap-2000-4 Creates files in /tmp/ with rw-rw-rw thus anyone can modify them. This is a security problem. /tmp]# ls -lstrAF 4 -rw-rw-rw- 1 suzanne suzanne 4 May 8 10:13 .305.af507 4 -rw-rw-rw- 1 jorg jorg 4 May 8 11:26 .305.df205 4 -rw-rw-rw- 1 jorg jorg 4 May 8 11:26 .305.db247 4 -rw-rw-rw- 1 mal mal 4 May 8 11:35 .305.7f87 4 -rw-rw-rw- 1 mal mal 4 May 8 11:51 .305.ff02 one temporary file is open for every imap connection to the server. So open few connections and see these unsafe temporary files.
This is a response I got from imapd author: "This is not a bug. This topic is covered in the IMAP toolkit FAQ."
Hmm. I don't see any reason at all for 666 permissions. I'll read the FAQ and see wether or not it is a security concern. I'd rather err on the side of caution. PINE and UW-IMAP have never had particularly good security records with temporary files, so I'm inclined to be suspicious. ;o) Thanks for the heads up.
Oops.. I don't need no steenken eenfo.. Dunno why I hit that..
Well, Mark Crispin surely was upset about even considering the though of changing anything. Oh well, I was polite about it anyway... Looks like we're on our own if we want to change it. I'm inclined to leave it as it is for the time being however because: A) I'm not familiar enough with the code to do anything about it without major time and effort. B) I've got bigger fish to fry right now. C) If it affects us, it affects every system using UW-IMAP. If someone else can come up with an adequate solution that doesn't break anything, I'll consider adding their changes. This major a change would not occur as an errata however, but would have to be a feature change for future release. D) There is not any public outcry about it or security threat from it perceived by the community at large it seems. I will continue to investigate this matter however, and consult with people who are knowledgeable in these sort of security matters but are unbiased towards the code. The author of any particular code can be sensitive to comments about changing it drastically as we have seen.
This problem is deep in nature and can not be fixed without breaking everything under the sun. Unless UW fixes the imap server themselves this problem will never be fixed. All inquiries I have made into this matter have turned up nothing, and I'm not willing to make our imap package different than everyone elses as it would be incompatible. If this is a problem on a given system, the solution is a baseball bat to the attacker.
As said above, this problem will not be fixed until either it is fixed upstream by UW, or there is some widespread vendor concensus to change imap's lockfiles and break all existing apps. It does not make me happy to close this as I want to fix the problem, but it is not feasible for us to break all existing software relying on this behaviour unless all vendors are willing to do the same. Even then, UW imap is not real open source under the DFSG so it would likely have to be approved by UW anyway. Real solution: don't use UW imap. Alternative: Start new imap server project on sourceforge. ;o)
*** Bug 112468 has been marked as a duplicate of this bug. ***