Issue with _dbus_write_socket on windows
hp at redhat.com
Sat Nov 18 13:04:34 PST 2006
Timothy Vismor wrote:
> The named mutex is a system-wide object. If you want one for the
> system bus and one for each session bus, you have to devise a
> suitable naming convention.
Found this suggestion on MSDN,
> If you are using a named mutex to limit your application to a single
> instance, a malicious user can create this mutex before you do and
> prevent your application from starting. To prevent this situation,
> create a randomly named mutex and store the name so that it can only
> be obtained by an authorized user. Alternatively, you can use a file
> for this purpose. To limit your application to one instance per user,
> create a locked file in the user's profile directory.
I *think* this is saying just use a lockfile and don't use the mutex at
all if you want per-user, though I guess it could be saying store the
mutex name in the lockfile.
File locking docs:
So autolaunch on Windows could use a locked file in the user's profile
dir in place of an X selection.
The bus address could simply be stored in the locked file.
The next question is what is that bus address. Right now Windows is
using TCP, but a problem is that it's unclear how to generate a per-user
TCP address. I guess a random port can be picked, but that's likely to
be evil (collide with other apps), I would think?
So it may be necessary to create a named pipe transport in addition to
the socket transport, generate a random name for the named pipe just as
we do for unix domain sockets, and then store the bus address (including
name of the pipe) in the lock file.
This would mean creating a new "named-pipe:name=blahblah" kind of
address for use on Windows.
I guess on Windows we could also use a window with messages instead of a
named pipe, I have no idea what kind of tradeoffs there might be. The
named pipe API _looks_ essentially equivalent to unix domain sockets...
More information about the dbus