Re: "orbit-<username>" dir in /tmp

[Michael Meeks <michael ximian com>]

Hi Jacob / Hema,

	[ Havoc, the problem is of people maliciously creating 
	  /tmp/orbit-$USER directories to disrupt local Unix Domain 
	  socket communications ].

On Mon, 2002-06-03 at 18:56, jacob berkman wrote:
> On Fri, 2002-05-31 at 09:20, Hema Seetharamaiah wrote:
> > On Linux, this directory will stay across reboots until perhaps the user
> > explicitly deletes it.
> 
> (this is not actually the case - some linux distributions clean /tmp on
> reboot so you can potentially see this problem on linux also)

	So - the problem exists; and I can see 2 possible solutions.

	a) use the users' homedir for the '.orbit-$(hostname)' directory
	   that would contain all the bonobo-activation lock files, and
	   linc socket nodes.

	The problem with this approach is that I've heard complaints about
GConf's problems with NFS and locking [ in the user directory ].
Secondly there is a definate, limit on the length of the sun_path that
uniquely identifies a UDS - posix defines 100 characters. Consequently a
complex path to /mnt/foo/home/user/.orbit-$(hostname)/linc-123123123123
uses ~ half of that, and possibly worse - perhaps not a very problematic
consideration.

	b) instead of having a defined /tmp/orbit-$(USER) we could scan
	   /tmp for orbit-$(USER)-%d where %d increments until we hit a
	   directory with the correct permissions [ or we could use the
	   opendir ordering if that is repeatably defined ].

	   This would keep a similar approach to the moment, keep the socket
paths short, but would involve a oneoff cost per app startup, to scan
the /tmp directory [ although this could in future be obviated with a
new API and bonobo-activation-server support ]. 

	So - clearly the current 'one path or bust' scheme is not workable, and
very prone to denial of service issues;

	I solicit advice on how best to solve the problem in anyone's opinion.

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot