Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 3753 - /tmp/.ICE-unix weirdness caused GNOME to run w/ umask 000
Summary: /tmp/.ICE-unix weirdness caused GNOME to run w/ umask 000
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 6.0
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
URL:
Whiteboard:
: 4714 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-06-27 01:24 UTC by mcornick
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-08-31 18:54:30 UTC


Attachments (Terms of Use)

Description mcornick 1999-06-27 01:24:11 UTC
[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-27 01:36:59 UTC
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 20:25:59 UTC
fixed in XFree86-3.3.3.1-53, in the next Raw Hide release...

Comment 3 Michael K. Johnson 1999-07-15 18:12:59 UTC
This should be released as an errata update.

Comment 4 Bill Nottingham 1999-07-29 16:01:59 UTC
it will be released with the 3.3.5 errata update when 3.3.5 becomes
available.

Comment 5 Preston Brown 1999-08-31 19:22:59 UTC
*** 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.