Permissions on key directories/files.

[Egbert Eich]

If the sticky bit is not set or the ownership of this directory
is not root we risk a man-in-the-middle attack. Even if the sticky bit
is set the owner of the directory is able to do the attack.
Therefore the function that attempts to create these directories
(if they don't exist) should fail hard and print a meaningful
error message.
It should be the responsibility of the install procedure and/or
the OS vendor to make sure that these directories exist and have the
correct ownership and permissions.
Letting x,g,kdm or whatever create these directories is just a 
convenience fix for people who have a habit to delete those directories.


Egbert.


Jim Gettys writes:
 > There are a number of files/directories that modern (and non-modern)
 > X based desktops depend on, and whose presence, ownership and
 > permissions are critical to proper functioning.
 > 
 > These include:
 > 	/tmp/.X11-unix		(containing the X server's unix 
 > 				domain socket)
 > 	/tmp/.ICE-unix		(containing libICE socket)
 > 
 > I'm sure there are others.  These two are expected to be owned
 > by root and accessible to everyone, with the sticky bit set on
 > the directory.  For those of you unaware of them, they are used
 > to store sockets in well known locations in the file system so
 > that clients can talk to the X server (Unix domain), or that
 > applications in your session can chat with each other using
 > ICE.
 > 
 > Problem statement:
 > 
 > If the ownership and permissions of files/directories like these are
 > incorrect, various things can fail, and in some cases, you end
 > up with very mysterious situations where you can't even log in
 > except as root.
 > 
 > I've observed this in mundane situations like needing to change
 > the UID/GID of my files, and forgetting to get them changed
 > appropriately.  They can, in pretty ordinary use, end up not
 > owned by root, particularly if you switch from startx to use
 > of {g,k,x}dm.
 > 
 > This instant, if you trigger this situation, you may or may not
 > have your session fail (in very obscure ways), but are very likely
 > to trigger a strange 5 second sleep that got put in some years
 > ago (whilke it is printing an error message you probably never
 > see) complaining about the ownership/mode of the directories.
 > We're removing the strange 5 second sleep in libICE
 > since it adds no value we can see.
 > 
 > But this begs the fundamental question: how to ensure that
 > directories or files that the desktop depends on are set
 > correctly on restart (at a minimum) of a login session, so that
 > these failures don't result in massive headaches in the field
 > (I once wasted hours on this sort of failure before happening
 > across the cause of the problem; in my case, it was some
 > bonobo related file/socket IIRC).
 > 
 > Two more obvious solutions include:
 >    o to decree that programs that initiate sessions (e.g. startx,
 > 	{g,k,x}dm) know what directories and files are essential
 > 	to correct inter-operation and get them set to a
 > 	correct state.
 >    o a small helper application that can get invoked at run time
 > 	if files/directories need resetting and are not set
 > 	correctly.
 > There may be other solutions.
 > 
 > Since I strongly suspect that this problem occurs for other
 > files and directories on current desktops, I think rather
 > than just fixing the libICE problem that we should see if we
 > can come up with one mechanism to kill as many birds as possible
 > that we can all share.
 > 
 > Either way, we need a standard on how to discover what needs
 > to be set to what mode that can be shared across different
 > invocation methods ((e.g. startx, {g,k,x}dm) or if we use
 > a suid helper application at run time.
 > 
 > Comments?  Suggestions? Alternatives?
 >                                 - Jim
 > 
 > (I opened http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=306
 > for this problem).
 > 
 > -- 
 > Jim Gettys <Jim.Gettys at hp.com>
 > HP Labs, Cambridge Research Laboratory
 >