Re: /tmp/.ICE-unix

[Havoc Pennington <hp redhat com>]

Seth Aaron Nickell <snickell Stanford EDU> writes: 
> Printing the data out to the commandline is also a silly approach. If this 
> represents a significant security violation, it should pop up a dialogue 
> warning the user, and offer to fix it (of course prompting for a root 
> password). 
> 
> I've seen this on too many systems for exit(1) to be a viable option. 
> That's a cop-out.

What would the dialog say? "Hi. Some weird permissions are mangled on
some weird file resulting in ICE authentication insecurity. Please
give your root password to do something you don't understand." ;-)

I don't think so. If it's a security issue (and I think it probably is
- whoever owns the dir can delete everyone else's ICE sockets), then
it's a cop-out if we ever let the situation arise. I think we've let
it arise because people haven't noticed the message or didn't think it
was important, because it doesn't fatally crash. This is an assertion
failure, in other words, it's not an expected error condition. At
least that's my interpretation. I would have put maybe a
g_assert_not_reached() in this spot, not sleep (5). It represents a
system bug.

I feel like there's a gap in my understanding however, because this
code is clearly meant to be run from the session manager, and the SM
is never running as root, and the code thus has no chance of creating
a root-owned directory; so I don't get how any session manager was
ever meant to get this right. Neither GNOME nor KDE appear to handle
this case (KDE has their own cut-and-paste of the ICE code for some
reason, but this piece of the code is unmodified). I don't think the
ancient xsm does anything special either.  

We need to track down whoever originally designed this code. ;-) Sadly
all the file says is Open Group and NCR Corporation. ;-)

The same code runs to create /tmp/.X11-unix, for the X server
connections, but I think in that case getting the perms right is done
by the xserver and involves running as root at least part of the time.
Clearly we can't run gnome-session as root.

I can imagine plenty of ways to create that dir with the right
permissions before gnome-session runs, but I am really curious what
the Right Way is.

Havoc