Bug 39685 - Unsafe permissions in /tmp files
Summary: Unsafe permissions in /tmp files
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: imap   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Keywords: Security
: 112468 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-08 15:55 UTC by Need Real Name
Modified: 2007-04-18 16:33 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-31 08:40:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2001-05-08 15:55:41 UTC
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

Comment 1 Need Real Name 2001-05-08 18:30:42 UTC
This is a response I got from imapd author:

"This is not a bug.  This topic is covered in the IMAP toolkit FAQ."

Comment 2 Mike A. Harris 2001-05-09 00:56:41 UTC
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.

Comment 3 Mike A. Harris 2001-05-09 01:00:29 UTC
Oops.. I don't need no steenken eenfo..  Dunno why I hit that..

Comment 4 Mike A. Harris 2001-05-11 04:44:19 UTC
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.

Comment 5 Mike A. Harris 2001-06-21 17:22:45 UTC
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

Comment 6 Mike A. Harris 2001-07-31 08:44:18 UTC
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)

Comment 7 Mike A. Harris 2004-02-27 10:30:02 UTC
*** Bug 112468 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.