Bug 3753 - /tmp/.ICE-unix weirdness caused GNOME to run w/ umask 000
/tmp/.ICE-unix weirdness caused GNOME to run w/ umask 000
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
6.0
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Preston Brown
: Security
: 4714 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-26 21:24 EDT by mcornick
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-31 14:54:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description mcornick 1999-06-26 21:24:11 EDT
[gnome-core-1.0.4-34, on Red Hat 6.0 i386 w/ all errata
applied as of today]

I'm still trying to figure out what caused this, but somehow
the /tmp/.ICE-unix directory on this system got into a state
wherein the socket that usually lives there during a GNOME
session couldn't be created. This had the effect of making
GNOME run w/ umask 000, causing all files created by that
session (such as stuff under $HOME/.gnome, and files created
by shells opened as xterms or gnome-terminals) to be
world-writeable.

Exiting GNOME, removing the /tmp/.ICE-unix directory, and
letting GNOME recreate it solved the problem.

This one is a bit odd because even during the malfunction,
/tmp/.ICE-unix was mode 1777 and owned by my UID and GID.
.xsession-errors showed
"_IceTransMakeAllCOTSServerListeners" failing with error 17
(file exists.)

I'm not sure what component of GNOME is at fault here (the
session manager perhaps?) but I know it happens somewhere
after gdm starts the session. (I switched to xdm and got the
same behavior.)
Comment 1 mcornick 1999-06-26 21:36:59 EDT
I've just confirmed that after:
1) removing /tmp/.ICE-unix
2) starting GNOME, letting it recreate /tmp/.ICE-unix
3) exiting GNOME
4) starting GNOME again
the problem reoccurs.

The errors in .xsession-errors are:
_IceTransSocketUNIXCreateListener: mkdir(/tmp/.ICE-unix) failed, errno
= 17
_IceTransMakeAllCOTSServerListeners: failed to create listener for
local
Comment 2 Bill Nottingham 1999-07-13 16:25:59 EDT
fixed in XFree86-3.3.3.1-53, in the next Raw Hide release...
Comment 3 Michael K. Johnson 1999-07-15 14:12:59 EDT
This should be released as an errata update.
Comment 4 Bill Nottingham 1999-07-29 12:01:59 EDT
it will be released with the 3.3.5 errata update when 3.3.5 becomes
available.
Comment 5 Preston Brown 1999-08-31 15:22:59 EDT
*** Bug 4714 has been marked as a duplicate of this bug. ***

Since XFree86-3.3.3.1-tmpdir.patch was added to
XFree86-3.3.3.1-52.src.rpm, these directories should exist,
be owned by root.root, and have 1777 perms at all time:

	/tmp/.X11-unix
	/tmp/.XIM-unix
	/tmp/.font-unix
	/tmp/.ICE-unix
	/tmp/.Test-unix

Otherwise, for instance, one user won't be able to
properly use gnome if there is already a /tmp/.ICE-unix
not owned by root.  There will be one if anyone but
root last used gnome and there is not a permanent
root-owned /tmp/.ICE-unix.

They should probably be created by
	XFree86-libs-3.3.3.1-52.i386.rpm
and
	XFree86-devel-3.3.3.1-52.i386.rpm
since those include the pertinent libraries.  However,
they should be created with care in case someone is
using X at the time they are installed.

The /etc/cron.daily/tmpwatch may also be affected, as
well as tmpwatch itself since it should not destroy
these directories if owned by root even if they are
old...

/tmp/.font-unix is somewhat special because of the way
/etc/rc.d/init.d/xfs is written.  It could be excluded
from this, or not (for uniformity).


To reproduce the problem, just install 6.0 + all current
patches and, as a regular user, try to use gdm to start
a gnome session twice in a row.  (Don't apply the fix
to see the unwanted behavior!!)  Then look at the
~user/.xsession-errors file.

There may be a more elegant solution by reviewing how
XFree86-3.3.3.1-tmpdir.patch works.

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