rpm -q imap
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
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.
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
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. ***