Created attachment 47860 [details] patch for configure.ac DBUS_SESSION_BUS_DEFAULT_ADDRESS, deduced in configure.ac, is not exported to config.h, so the default session bus address used in dbus lib maybe inconsistent with the one in session.conf Patch attached.
This is much messier than you think, unfortunately. There are two things that DBUS_SESSION_BUS_DEFAULT_ADDRESS might mean: * the address that a session bus dbus-daemon's DBusServer should listen on - this is more like an equivalence class of addresses, like "nonce-tcp:" or "unix:tmpdir=/tmp" - this is the DBUS_SESSION_BUS_DEFAULT_ADDRESS shell variable in configure.ac, and the resulting @DBUS_SESSION_BUS_DEFAULT_ADDRESS@ substitution in dbus-env.bat, session.conf.in and session.conf.cmake * the address that an application wanting the session bus should connect its DBusConnection to - this is the DBUS_SESSION_BUS_DEFAULT_ADDRESS cpp macro in dbus-internals.h, and is not the same (!) Unhelpfully, the CMake build system (which is mainly used on Windows) defines the DBUS_SESSION_BUS_DEFAULT_ADDRESS cpp macro to be the same thing as the shell variable from configure.ac. I'm pretty sure that's wrong, though. You can't connect to "nonce-tcp:", because which IP address and port would you connect to? You can't connect to "unix:tmpdir=/tmp", because which socket in /tmp should you use? The address that the DBusServer actually ends up listening on is something like "nonce-tcp:host=127.0.0.1:port=12345" or "unix:abstract=/tmp-iG52sc3jLf", unique per dbus-daemon. On Linux, the way this works is: * dbus-daemon's DBusServer listens on "unix:tmpdir=/tmp" and ends up with an address like "unix:abstract=/tmp/dbus-iG52sc3jLf" * if DBUS_SESSION_BUS_ADDRESS is found in the environment (its value is, again, something like "unix:abstract=/tmp/dbus-iG52sc3jLf"), applications connect to that * otherwise, the "default address" for clients (the DBUS_SESSION_BUS_DEFAULT_ADDRESS cpp macro) is "autolaunch:" which uses dbus-launch to either retrieve a session bus address from an X property, or start a new dbus-daemon and advertise it in the same X property On Windows, there seems to be another implementation of autolaunch, using named mutexes or something instead of X properties. Does it work? If not, fixing that and making it work like the one we use in X is probably the most useful thing to do.
cmake/dbus-env.bat.cmake contains: set DBUS_SESSION_BUS_ADDRESS=@DBUS_SESSION_BUS_DEFAULT_ADDRESS@ This one ought to be an address that clients can connect to, not a server address. The <listen> address in session.conf does need to be a server address, though; because there can be more than one session at once, it needs to be something generic where multiple servers can get different addresses, like "nonce-tcp:" (with the implicit "port 0 -> listen on a random port") or "unix:tmpdir=/tmp". Here's the (only) use of DBUS_SESSION_BUS_DEFAULT_ADDRESS in the actual source code: /* The DBUS_SESSION_BUS_DEFAULT_ADDRESS should have really been named * DBUS_SESSION_BUS_FALLBACK_ADDRESS. */ if (bus_connection_addresses[DBUS_BUS_SESSION] == NULL) bus_connection_addresses[DBUS_BUS_SESSION] = _dbus_strdup (DBUS_SESSION_BUS_DEFAULT_ADDRESS); if (bus_connection_addresses[DBUS_BUS_SESSION] == NULL) return FALSE; This block is reached if _dbus_lookup_session_bus_address() returns TRUE (success) while setting "supported" to FALSE, which happens on Windows and on non-Mac Unix. Non-Mac Unix, when built with autotools (the normal configuration), falls through to using X11-based "autolaunch:" which is correct. Non-Mac Unix, when built with cmake, will try to use (in practice) unix:path=/tmp, which isn't right: you can listen on that but you can't connect to it. Windows, when built with autotools, will try to do autolaunch. I have no idea whether this works, but it should. Windows, when built with cmake, will try to use "nonce-tcp:" which I don't think is right - there's no port number, so you can't connect to it, surely? Incidentally, the DBUS_SYSTEM_BUS_DEFAULT_ADDRESS on Unix builds with cmake is also wrong; it should be unix:path=/var/run/dbus/system_bus_socket or similar, but is currently set to "unix:tmpdir=" which I don't think even means anything?
Wonderful comments. That makes sense.
> On Windows, there seems to be another implementation of autolaunch, using named > mutexes or something instead of X properties. Does it work? yes, see http://dbus.freedesktop.org/doc/dbus-specification.html#meta-transports-autolaunch We stumbled about this misconception also on windows and introduced a separation of the client default bus address like DBUS_SESSION_BUS_CLIENT_DEFAULT_ADDRESS (see http://lists.freedesktop.org/archives/dbus/2010-June/012917.html) For the server part the already available DBUS_SESSION_BUS_DEFAULT_ADRESS or a rename to DBUS_SESSION_BUS_SERVER_DEFAULT_ADDRESS may be fine.
Commit fdab4af0f4748f1fb is related to this (it fixes the use of bare "nonce-tcp:" as something to connect to), but also changes the default system bus address on Windows to autolaunch:. Does Windows even have a system bus? Last I looked, D-Bus was not an OS component, so the answer is "no". I'm also pretty sure auto-launching a session bus is not the right way to get a system bus. Please do not commit unreviewed changes. We have a review procedure for a reason, even when it's annoying (I'm as slowed down by it as the next hacker, but I value having a reviewer spot my mistakes more than I value insta-applying changes). This goes (at least) double for the 1.4 branch, which is meant to be a "safe" stable branch.
(In reply to comment #5) > Commit fdab4af0f4748f1fb is related to this (it fixes the use of bare > "nonce-tcp:" as something to connect to) ... but also causes collateral damage in which dbus-daemon is asked to listen on "autolaunch:", as far as I can tell. I've reverted it, and I have a series of patches for discussion.
Created attachment 55128 [details] [review] [1/3] Don't use DBUS_SESSION_BUS_DEFAULT_ADDRESS on the client side Instead, hard-code "autolaunch:" because that's always what we want to fall back to anyway. Some background for this: Under autotools, this was never defined by the build system, only by dbus-internals.h, so this is not a change in behaviour. Under cmake, it was previously defined by the build system. However, its value on Unix was meaningless (it turns out to be an address that can neither be listened on nor connected to, because it typically consists of unix:path=/tmp) so there is no loss of functionality there. Its value on Windows under cmake was recently changed from "nonce-tcp:" to "autolaunch:", but what we actually seem to want is to listen on "nonce-tcp:", but fall back to "autolaunch:" if no address is available. --- Review and testing for Windows requested.
Created attachment 55129 [details] [review] [2/3] cmake: use the same default system bus address as for autotools The system bus is unsupported (and rather meaningless) on Windows anyway, so we can use anything. Also, make it clear that it has to be a "specific" address that can be listened on *and* connected to, like unix:path=/xxx - a listen-only address like unix:tmpdir=/xxx or nonce-tcp: would not be suitable.
Created attachment 55130 [details] [review] [3/3] Clarify the meaning of the session bus default address Now that this is unquestionably only a listening address, we can be considerably clearer about it. Also, set the same default in cmake as in autotools, so that it works "out of the box" in cmake; and respect the --with-dbus-session-bus-default-address option everywhere, not just on Windows.
ssh://people.freedesktop.org/~smcv/dbus.git default-address-38201 Ralf, any chance you could test this on Windows? I believe this provides significantly more clarity/correctness than what we currently have. I'd like to get this in before 1.6, which Lennart apparently wants soon.
(In reply to comment #7) > Created attachment 55128 [details] [review] [review] > [1/3] Don't use DBUS_SESSION_BUS_DEFAULT_ADDRESS on the client side > > Instead, hard-code "autolaunch:" because that's always what we want to > fall back to anyway. Autolaunch protocol on windows currently has an extended meaning as on unix - It has additional parameters http://dbus.freedesktop.org/doc/dbus-specification.html#meta-transports-autolaunch which are used for the dbus client library as configure time default value. The default client connection string for all KDE on windows builds is currently "autolaunch:scope=install-path", which means server: choose a free tcp port on windows and publish the address in a shared memory segment which name is calculated from the scope attribute. client: fetch the real client connection string from a shared memory segment which name is calculated from the scope attribute, if no address is available auto start dbus daemon and refetch and retry to connect. How could the client default connection string be provided at configure time, when DBUS_SESSION_BUS_DEFAULT_ADDRESS is not available to set the client side default address ? By introducing DBUS_SESSION_BUS_CLIENT_DEFAULT_ADDRESS or in another way?
(In reply to comment #11) > server: > choose a free tcp port on windows and publish the address in a shared memory > segment which name is calculated from the scope attribute. So on Windows it's meaningful to "listen on" "autolaunch:"? Or do you still use "nonce-tcp:" as the default listening address, and additionally publish its address as a side-effect? The closest equivalent on Unix is that dbus-launch directs dbus-daemon to listen on its default session listening-address (which is "unix:tmpdir=...") and tell it that address, then publishes that address in an X11 window. Listening on "autolaunch:" isn't meaningful on Unix, and "connecting to" "autolaunch:" actually means "run dbus-launch --autolaunch and see where it tells you to connect". It looks as though the default addresses in the autotools build system have never worked on Windows... > How could the client default connection string be provided at configure time, when DBUS_SESSION_BUS_DEFAULT_ADDRESS is not available to set the client side > default address ? > > By introducing DBUS_SESSION_BUS_CLIENT_DEFAULT_ADDRESS or in another way? Yeah, if hard-coding "autolaunch:" isn't sufficient, then I think we should have an extra configure option/cmake variable.
(In reply to comment #8) > The system bus is unsupported (and rather meaningless) on Windows anyway, Could you confirm whether you consider this to be true, please?
(In reply to comment #12) > So on Windows it's meaningful to "listen on" "autolaunch:"? It appears the answer is "yes". Also, executive summary: autolaunching is horrible, and doubly so if you care about more than one platform. It appears that the reason autolaunching doesn't work "out of the box" on Windows, and the reason your patch to fix that broke Unix, is that autolaunching on each of Windows, Mac (with launchd) and Unix is completely different :-( At a high level, the precedence is currently: * connect to $DBUS_SESSION_BUS_ADDRESS (top priority) * connect to the result of _dbus_lookup_session_address() if supported * if built with cmake: - connect to DBUS_SESSION_BUS_DEFAULT_ADDRESS as configured by cmake else: - connect to "autolaunch:" and then platform-dependent magic happens in the "autolaunch:" implementation. ---- On Windows, a dbus-daemon can listen on "autolaunch:" (with an optional scope parameter), and autolaunching won't work unless the session bus's default configuration does so. Behind the scenes, this actually listens on an arbitrary TCP port bound to localhost (as if for "tcp:host=localhost,bind=localhost", but it's hard-coded) and publishes the resulting tcp:blahblah address in a global shared memory page protected by a named mutex. These are shared between all processes on the system, so as far as I can tell, if there's more than one logged-in user, they can easily DoS each other by creating the mutex/shm page that the other user will want to use... (They might even be able to cause another user to connect to a fake session bus, I'm not sure exactly what the implications are.) As I thought, "autolaunch:" doesn't make sense for the system bus (if that's even a thing that can exist on Windows). It's not clear to me what dbus-launch does on Windows: dbus-launch-win.c just seems to start a new dbus-daemon.exe. What's the point of dbus-launch-win.c? Do you actually use it? Does it have any advantage over just running dbus-daemon.exe directly? The magic is divided between _dbus_get_autolaunch_address and the service-side autolaunch transport: * _dbus_get_autolaunch_address locks a global mutex and looks for a published address * if none found, it runs dbus-daemon.exe and waits for it to publish its address _dbus_lookup_session_address exists but does nothing. ---- On traditional Unix (notably Linux) with X11, you can't listen on "autolaunch:", and the session bus's default configuration listens on "unix:tmpdir=/tmp" (but in strange configurations with a shared NFS home directory, people sometimes reconfigure it to tcp:bind=192.168.0.1 or something). That's a listen-only address - the address the session bus actually ends up with is random (unix:path=/tmp/58w4fjmf9yg or tcp:host=192.168.0.1,port=6835 or something). The dbus-daemon doesn't publish its own address, because that would make it depend on X11. Instead, the helper program dbus-launch, run with the --autolaunch option, is responsible for: * checking whether there's an existing dbus-daemon, and if so, getting its real address from an X11 window and printing it * if not, starting one, publishing its address in an X11 window and printing its address and the autolaunch code just runs it and reads the address. The magic is all in _dbus_get_autolaunch_address() and dbus-launch: the dbus-daemon doesn't do anything special. _dbus_lookup_session_address exists but does nothing. ---- On Mac OS X with launchd, launchd (part of the OS) listens on a Unix socket on our behalf, and you can tell a dbus-daemon to listen on "launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET" (a valid *listening* address). There's some magic involving launchd which I don't fully understand, and in any case it apparently doesn't fully work. The dbus-daemon is given an already-listening file descriptor and a corresponding path; it prepends "unix:path=" to that path (hard-coded) to get its own address. On the client side, _dbus_lookup_session_address() asks launchd where to find the dbus-daemon, then prepends "unix:path=" (again, hard-coded). This time, _dbus_get_autolaunch_address() does nothing (and isn't used). It's not clear to me why this isn't just autolaunch, like on traditional Unix, but whatever...
(In reply to comment #11) > The default client connection string for all KDE on windows builds is > currently "autolaunch:scope=install-path" So it seems the available scopes are *install-path (or install-path as a backwards-compat alias), *user, or arbitrary strings. Could you explain why you'd want more to vary the scope? I'm trying to get an idea of what Windows D-Bus needs, and why it isn't the same as Unix... In cases where you want a "sub-session" (like running regression tests), is it possible to set DBUS_SESSION_BUS_ADDRESS for a tree of processes rather than doing things differently within dbus?
One thing that might simplify things is if autolaunch on Windows became more like it is on Unix, so the client side (_dbus_get_autolaunch_address()) had responsibility for the entire auto-launching process, and the service side (dbus-daemon/DBusServer) was just listening on a (non-hard-coded) address. A potential problem with that is that on Unix it's easy to get information out of a subprocess via pipes and fork/exec, whereas the process model for Windows seems to be rather different. Does dbus-daemon --print-address work on Windows? Would it be reasonably easy for its parent process to read the address from a pipe and put it in the shm segment before it releases the mutex? If that's not feasible, then I think having two configurable addresses is probably the only way to do this.
Created attachment 56880 [details] [review] Split DBUS_SESSION_BUS_DEFAULT_ADDRESS into listen, connect addresses On Unix, the connect address should basically always be "autolaunch:" but the listen address has to be something you can listen on. On Windows, you can listen on "autolaunch:scope=*install-path", for instance, and the dbus-daemon is involved in the auto-launching process. --- Straw-man patch for two separate default addresses, with platform-specific defaults. Does it look vaguely right/usable? I used "autolaunch:scope=*install-path" as the Windows default here, mainly to make it obvious what would change if the default should be different between Unix and Windows; but if you in fact just want "autolaunch:" that'd be fine too. What default would you actually want in KDE-for-Windows? Is there any reason why you'd want to change the default in other projects? I wonder whether, if we make the default platform-specific, we can remove the configure option again, and just have it hard-coded-per-platform?
(In reply to comment #16) > Does dbus-daemon --print-address work on Windows? It turns out it doesn't. dbus-pipe-win.c assumes that fd_or_handle is a HANDLE, but dbus-pipe.c assumes it's a libc file descriptor. This is obviously broken; I don't know whether the solution is "stop using pipes on Windows, consider them to be Unix-specific" or "distinguish between libc _pipe pipes and Windows HANDLE pipes".
(In reply to comment #13) > (In reply to comment #8) > > The system bus is unsupported (and rather meaningless) on Windows anyway, > > Could you confirm whether you consider this to be true, please? unsupport currently yes meaningless - I would say currently there is no use case, but this may change in the future when kde or gnome applications using system bus may be ported to windows.
(In reply to comment #15) > (In reply to comment #11) > > The default client connection string for all KDE on windows builds is > > currently "autolaunch:scope=install-path" > > So it seems the available scopes are *install-path (or install-path as a backwards-compat alias), *user, or arbitrary strings. > > Could you explain why you'd want more to vary the scope? I'm trying to get an idea of what Windows D-Bus needs, and why it isn't the same as Unix... Not sure, what you mean with "more to vary the scope" - using arbitray strings make all possible you like to want, like debug and release and so one. I remember a thread on the dbus list where exactly this has been requested also for linux. > > In cases where you want a "sub-session" (like running regression tests), is it possible to set DBUS_SESSION_BUS_ADDRESS for a tree of processes rather than > doing things differently within dbus? In the recent dbus on Windows state, there is no real session bus, normally started on user logon. Therefore there is no environment having recent SESSION BUS ADDRESS. In the recent state of KDE on windows there are many kde application installations side by side possible (the community release, single package installers). Each installation have it's own stack of dbus services, there is currently no sharing of dbus services, mainly to avoid problems with different dll versions. Also KDE on Windows installations do not set/use global paths to avoid dll loading problems from different installations. The dbus-daemon is autostarted by any kde application through the dbus shared libary linked into the client application. Therefore dbus-daemon need to use a different session listen address for each installation and the client need to get the address it should connect to from the related running dbus-daemon. This all is set by using autolaunch:scope=*install-path Hope that help to understand the recent situation.
(In reply to comment #14) > (In reply to comment #12) > > So on Windows it's meaningful to "listen on" "autolaunch:"? > > It appears the answer is "yes". Also, executive summary: autolaunching is horrible, and doubly so if you care about more than one platform. > > It appears that the reason autolaunching doesn't work "out of the box" on Windows, and the reason your patch to fix that broke Unix, is that autolaunching on > each of Windows, Mac (with launchd) and Unix is completely different :-( yes, because of different working environments > > Behind the scenes, this actually listens on an arbitrary TCP port bound to localhost (as if for "tcp:host=localhost,bind=localhost", but it's hard-coded) and > publishes the resulting tcp:blahblah address in a global shared memory page protected by a named mutex. These are shared between all processes on the system, > so as far as I can tell, if there's more than one logged-in user, they can easily DoS each other by creating the mutex/shm page that the other user will want > to use... > > (They might even be able to cause another user to connect to a fake session bus, I'm not sure exactly what the implications are.) That the reason why I wrote in the spec: Disclaimer: The recent implementation is in an early state and may not work in all cirumstances and/or may have security issues. Because of this the implementation is not documentated yet. > > As I thought, "autolaunch:" doesn't make sense for the system bus (if that's even a thing that can exist on Windows). > > It's not clear to me what dbus-launch does on Windows: dbus-launch-win.c just seems to start a new dbus-daemon.exe. What's the point of dbus-launch-win.c? Do > you actually use it? Does it have any advantage over just running dbus-daemon.exe directly? > dbus-launch-win.c contains some comments about this. It is used by the kde session start wrapper "kdeinit4" to start dbus.
(In reply to comment #17) > Split DBUS_SESSION_BUS_DEFAULT_ADDRESS into listen, connect addresses > > On Unix, the connect address should basically always be "autolaunch:" > but the listen address has to be something you can listen on. > > On Windows, you can listen on "autolaunch:scope=*install-path", for > instance, and the dbus-daemon is involved in the auto-launching process. Ralf, could you test this on Windows, please? I think this is what we want in the short term, as a version of your commits fdab4af0/e15ebf32a that also works on Unix. As noted, I made the default "autolaunch:scope=*install-path" on Windows, but if "autolaunch:" would be more suitable, that's fine too. If this achieves what you were trying to do with fdab4af0/e15ebf32a, it'd be good to have in dbus-1.6. (In reply to comment #19) > unsupport currently yes > > meaningless - I would say currently there is no use case, but this > may change in the future when kde or gnome applications using system > bus may be ported to windows. OK, thanks. I'm going to assume that if a system bus is wanted on Windows in future, it'll need new design, so Attachment #55129 [details] still makes sense for now. The things that are needed for a meaningful system bus are: * one per OS instance (i.e. real or virtual machine); * runs as an OS-level service, rather than being owned by a particular user; * any user may connect; * users are authenticated/identifiable If it doesn't have those properties, then it isn't the system bus. Which of these are currently implementable on Windows? (This might mean that certain system-bus services would have to move to the session bus or some sort of private bus if ported to Windows.) (In reply to comment #20) > > Could you explain why you'd want more to vary the scope? I'm trying to get an idea of what Windows D-Bus needs, and why it isn't the same as Unix... > > Not sure, what you mean with "more to vary the scope" - using arbitray > strings make all possible you like to want, like debug and release > and so one. I remember a thread on the dbus list where exactly this > has been requested also for linux. My position on this is: there should be one session bus per "session", where a login to X is normally a login session, and explicitly starting a new session (e.g. by running dbus-launch or dbus-daemon, or dbus-run-session with Bug #39196 fixed) also creates a session. If, in KDE-for-Windows, you want to say that each copy of dbus-daemon.exe bundled with an application or group of applications defines its own "session", then that's fine too. The original Unix autolaunch pseudo-transport is designed as a way to start one dbus-daemon per login session, on-demand (in practice, one per X session, because nothing else actually works). Your autolaunch transport seems to be designed to be a way to start up to one "session" per bundle of applications per actual user logon, on-demand (not quite the same thing, but close). > The dbus-daemon is autostarted by any kde application through the dbus shared libary linked into the client application. Therefore dbus-daemon need to use a > different session listen address for each installation and the client need to get the address it should connect to from the related running dbus-daemon. > This all is set by using autolaunch:scope=*install-path OK, so would "autolaunch:scope=*install-path" be a sensible default setting on Windows? Also, is there any practical reason why you'd ever want to use autolaunch: with a scope argument that is not "*install-path"?
(In reply to comment #22) > (In reply to comment #17) > > Split DBUS_SESSION_BUS_DEFAULT_ADDRESS into listen, connect addresses > > > > On Unix, the connect address should basically always be "autolaunch:" > > but the listen address has to be something you can listen on. > > > > On Windows, you can listen on "autolaunch:scope=*install-path", for > > instance, and the dbus-daemon is involved in the auto-launching process. > > Ralf, could you test this on Windows, please? I think this is what we want in the short term, as a version of your commits fdab4af0/e15ebf32a that also works > on Unix. > I applied both patches today and compiled with msvc express 2010 with and without defining DBUS_SESSION_BUS_LISTEN_ADDRESS and DBUS_SESSION_BUS_CONNECT_ADDRESS, the patches works as expected.
(In reply to comment #22) > As noted, I made the default "autolaunch:scope=*install-path" on Windows, but if "autolaunch:" would be more suitable, that's fine too. > > If this achieves what you were trying to do with fdab4af0/e15ebf32a, it'd be good to have in dbus-1.6. yes > > (In reply to comment #19) > > unsupport currently yes > > > > meaningless - I would say currently there is no use case, but this > > may change in the future when kde or gnome applications using system > > bus may be ported to windows. > > OK, thanks. I'm going to assume that if a system bus is wanted on Windows in future, it'll need new design, so Attachment #55129 [details] still makes sense for now. yes > > The things that are needed for a meaningful system bus are: should we not discuss this on a separate feature request to not pollute this thread ? > > (In reply to comment #20) > > > Could you explain why you'd want more to vary the scope? I'm trying to get an idea of what Windows D-Bus needs, and why it isn't the same as Unix... > > > > Not sure, what you mean with "more to vary the scope" - using arbitray > > strings make all possible you like to want, like debug and release > > and so one. I remember a thread on the dbus list where exactly this > > has been requested also for linux. > > My position on this is: there should be one session bus per "session", where a login to X is normally a login session, and explicitly starting a new session > (e.g. by running dbus-launch or dbus-daemon, or dbus-run-session with Bug #39196 fixed) also creates a session. > > If, in KDE-for-Windows, you want to say that each copy of dbus-daemon.exe bundled with an application or group of applications defines its own "session", then > that's fine too. this is the recent state - when dbus and dbus applications on Windows will be more mature in the future and dbus is available as a standalone package there could also be a login session bus, where KDE application could connect to instead to the "install path session bus". [1] > The original Unix autolaunch pseudo-transport is designed as a way to start one dbus-daemon per login session, on-demand (in practice, one per X session, > because nothing else actually works). On windows there are different needs, so there are more use cases. The login session bus is provided by the autolaunch:scope=*user listen and connect address. > Your autolaunch transport seems to be designed to be a way to start up to one "session" per bundle of applications per actual user logon, on-demand (not quite > the same thing, but close). Let me say this with may words: the autolaunch pseudo or meta-protocol on windows provides an implementation independent way of defining different session bus types; by using the scope parameter. Login session busses for example are possible on windows using the scope=*user attribute without any required 3rdparty involvement in the opposite to unix, where a complete login session uses the default 'autolaunch' address, plus required 3rdparty involvement to make sure that clients can get the connect address (the shell). On windows the default 'autolaunch' address means a complete generic bus. The conclusion is that the default unix 'autolaunch' protocol means an incomplete session bus. The advantage of these all-inclusive strategy is, that it is independent from any windows environment. Using global or user related enviroment variables is one major source of problems for example in portable installations. If things need to be changed, it can be all done in dbus. > > The dbus-daemon is autostarted by any kde application through the dbus shared libary linked into the client application. Therefore dbus-daemon need to use a > > different session listen address for each installation and the client need to get the address it should connect to from the related running dbus-daemon. > > This all is set by using autolaunch:scope=*install-path > > OK, so would "autolaunch:scope=*install-path" be a sensible default setting on Windows? if your expected time line is more than two years I would say now, but in the near future i would say yes. If the default should be the login session bus, it has to be "autolaunch:scope=*user". For KDE on windows application it will be overriden with the "*install-path" scope on configure time. If a dbus application using *install-path scope on configure time would like to use the login session bus later, there is currently no way to change the scope on runtime. The application requires an updated dbus packages with a 'scope=*user' configured address. An alternative approach would be to add the following feature http://lists.freedesktop.org/archives/dbus/2010-June/012914.html > Also, is there any practical reason why you'd ever want to use autolaunch: with a scope argument that is not "*install-path"? yes, see my comments about scope=*user above.
(In reply to comment #24) > > If this achieves what you were trying to do with fdab4af0/e15ebf32a, it'd be good to have in dbus-1.6. > > yes If you would like this to happen and you've reviewed the two patches, please say so and they can be merged. > On windows there are different needs, so there are more use cases. > The login session bus is provided by the autolaunch:scope=*user listen > and connect address. > Let me say this with may words: the autolaunch pseudo or meta-protocol > on windows provides an implementation independent way of defining different > session bus types; by using the scope parameter. I'm not sure that this is really the right "layer": if the meaning of "session bus" doesn't (at least approximately) match what it means on Unix and in the D-Bus Specification, then it should be a separate well-known bus, possibly one that only exists on Windows (like the DBUS_BUS_USER that's been proposed several times for Unix). You seem to have at least two meanings for "session bus" in mind. One notable problem with having "the per-user-per-install-path bus" and "the per-user bus" both be DBUS_BUS_SESSION is that if an application author needs to access one service on each of those, it's not at all obvious how (they'd have to use dbus_connection_open_private() for at least one of the buses). On the other hand, if you have (say) DBUS_BUS_WINDOWS_INSTALLPATH and DBUS_BUS_WINDOWS_USER, you lose the guarantee that every process sees messages in the same order; so if possible, it's desirable to say "one set of semantics is Right, the other is Wrong, we're only going to use one". > Login session busses for example are possible on windows > using the scope=*user attribute without any required 3rdparty > involvement in the opposite to unix, where a complete login session > uses the default 'autolaunch' address, plus required 3rdparty involvement > to make sure that clients can get the connect address (the shell). I'm not sure you're understanding Unix "autolaunch:" correctly here: its design is better than you think (it's an open question whether it actually works - the implementation of dbus-launch is pretty shaky). For comparison, here's the design: The normal way to get the session bus address on a modern Linux distribution is to inherit the DBUS_SESSION_BUS_ADDRESS environment variable from a parent process. The parent process of the entire login session (Xsession) typically uses dbus-launch to start a dbus-daemon and set that environment variable to its address. This isn't auto-launching, it's an environment variable that overrides and prevents auto-launching. If a process doesn't have that environment variable, a default is used. That default is "autolaunch:". libdbus interprets that as: run dbus-launch --autolaunch, and use the resulting address. dbus-launch stores its dbus-daemon's address in a hidden X11 window, and checks for it before starting a new one, so if multiple processes in the same X11 session use autolaunch, the idea is that they'll all share one dbus-daemon. I'm not sure whether this actually works, but the design is that it should... This seems pretty similar to the way you store the dbus-daemon's address in a Windows global mutex with a well-known name, with two significant differences: * Windows global mutexes don't add extra library dependencies, but X11 windows do, so the Unix/X11 implementation uses a helper binary (dbus-launch) whereas the Windows implementation can be entirely inside libdbus; * on Windows you can "listen on" an autolaunch address, which means part of the implementation of autolaunch is inside dbus-daemon; whereas on Unix, dbus-launch does all the extra work and dbus-daemon is just listening on a normal Unix socket > The advantage of these all-inclusive strategy is, that it is > independent from any windows environment. Using global or user > related enviroment variables is one > major source of problems for example in portable installations. I can see that this makes DBUS_SESSION_BUS_ADDRESS problematic for you, so you're more reliant on autolaunching than Unix D-Bus is; on Unix we can generally rely on the distribution's X session startup to set DBUS_SESSION_BUS_ADDRESS, so autolaunching is only needed in weird cases. > If a dbus application using *install-path scope on configure > time would like to use the login session bus later, there is > currently no way to change the scope > on runtime. Right, but why would you want to? You've explained various ways to chose between *user and *install-path (some implemented and some just proposed), but what I'm trying to ask is why you would want to use *user, and why you would want to use *install-path. If one of those options is "obviously better than" the other, then we should always use it, and never the other one (there's no point in something being configurable if you would never have a valid reason to configure it). If there are advantages and disadvantages to both, what are they, and how should application distributors (and D-Bus maintainers) choose which one to use?
(In reply to comment #25) > If you would like this to happen and you've reviewed the two patches, > please say so and they can be merged. Having waited 3 months for this, I'm going to give up and release 1.6 anyway. > If there are > advantages and disadvantages to both [*user and *install-path], > what are they, and how > should application distributors (and D-Bus maintainers) choose > which one to use? I would still like to know which of these is appropriate in which situations, so we can make an informed decision about the right default.
My $0.02: autolaunch:scope=*install-path seems to be the correct default on Windows. There's no "system-level" DBus installation, no system-bus and no session-bus. You can only count on a bus being present if you know that someone installed DBus and created the bus -- and if you know that, then you can use their DBus library, and then install-path will hook you up to their bus by default. If you distribute DBus yourself, then you assume that no bus is present, and you're given your own scope. This also avoids potential issues with different DLL versions being installed on the system (since applications will often distribute their own, under the assumption that no DBus installation exists). "autolaunch:" and "autolaunch:scope=*user" seem to be the closest equivalents to the UNIX system- and session bus respectively, but both are rendered somewhat pointless by the fact that DBus isn't available as an OS service: you have to install it yourself, or at least know that someone else has installed it, and if you know that, why not just use scope=*install-path (and avoid versioning problems as well)? In the end, DBus isn't really a first-class citizen on Windows: it's a "bring your own bus" environment, so in all common cases, scope=*install-path seems to be the right default. If two applications can agree to use the same DBus library, then they'll probably expect to connect to the same bus by default as well. As to whether you can remove the configure option entirely and just hardcode a per-platform default, I'm not sure. "scope=*install-path" definitely seems like the correct default on Windows, but because DBus will typically be installed by the applications that need it, rather than as a shared OS component, more liberal configure options might be desirable (you only need to configure something that works for your application(s), not necessarily for the entire system, so perhaps some would want to configure it to default to "autolaunch:scope=some-unique-string" at build-time?) I'd say go ahead in either case. You can probably get away with removing the configure option since no one has objected so far, but leaving it in might be better for some people. As long as the default on Windows is set to "autolaunch:scope=*install-path", the situation will be vastly better than it's been until now.
On the mailing list, Alex Larsson wrote: > GDbus on win32 doesn't support any of the scopes. install-path for > instance doesn't seem to be a great choice for gdbus as it ties the > implementation-independent protocol to an implementation (and gdbus is a > non-libdbus client implementation). so... (In reply to comment #27) > autolaunch:scope=*install-path seems to be the correct default on Windows. ... if this is the case, please convince the GDBus people (mainly Alex L and David Z) that it's true :-) Equivalently, Alex/David: if "autolaunch:" is the most suitable default, please explain why it is better than "autolaunch:scope=*install-path" or "autolaunch:scope=*user". > As to whether you can remove the configure option entirely and just hardcode a > per-platform default, I'm not sure. I wasn't planning to remove the configure option now that we have it, but it does need to be two separate options for the listen and connect sides (because otherwise there's no correct default on Unix, where autolaunch: isn't a valid listening address). On Windows, the two can just be the same. I do want the default, when compiling with either Autotools or CMake on either Windows or Unix, to be sane, so people don't have to waste time finding the right mailing list thread that explains that the default "nonce-tcp:" on Windows is a trap and you should use one of the various "autolaunch:" scopes. The per-platform default should also be the same for each build system. On Unix I think it's uncontroversial that the default should be "autolaunch:" on the connecting side, and "unix:tmpdir=/tmp" on the listening side. On Windows I think it's uncontroversial that the default should be the same on the listening and connecting sides, and it should be some sort of autolaunch address. I don't really care whether it's autolaunch: or autolaunch:scope=*install-path or something else, but we have to pick one somehow. If the chosen option is "autolaunch:scope=*install-path" then someone should review my two patches attached to this bug, and either say "yes, please apply these" or "no, here are the things you need to change". If the chosen option is plain "autolaunch:" (or some third option) then someone should review my two patches attached to this bug, and either say "yes, please apply these, but with autolaunch: instead of autolaunch:scope=*install-path" or "no, here are the things you need to change". Until someone reviews my patches and either approves them or gives specific, constructive comments, they're not going to get applied.
(In reply to comment #28) > Equivalently, Alex/David: if "autolaunch:" is the most suitable default, please > explain why it is better than "autolaunch:scope=*install-path" or > "autolaunch:scope=*user". I think "autolaunch:scope=*install-path" isn't very useful, because a) it only applies to the weird configuration where you are porting a desktop environment to Windows (which in itself is a desktop environent - go deeper). I call this weird because the norm should be that you port applications to Windows and make them integrate well with the existing DE; and b) you can achieve the same by just setting DBUS_SESSION_BUS_ADDRESS in your desktop environment login script; and c) even when running a DE, you want to run e.g. a 3rd party tool (say, someone packaged up d-feet or gdbus.exe on Windows (latter exists) to be able to easily connect to the session bus even not built against the same "install-path" I don't think "autolaunch:scope=*user" is useful either because that it's the only scope left. So I think then only valid address for the autolaunch scope would be "autolaunch:". I haven't had time to look at the patches posted (sorry), but here is what I would like to see - the scope variable for autolaunch should be removed from the D-Bus spec (this would leave no variables for autolaunch - which would help simplify the implementations and the spec) - the D-Bus spec should be more precise concerning how autolaunch works on Windows. E.g. the current paragraph, this one On start, the server opens a platform specific transport, creates a mutex and a shared memory section containing the related session bus address. This mutex will be inspected by the dbus client library to detect a running dbus session bus. The access to the mutex and the shared memory section are protected by global locks. lacks important detail - it forces implementors to go look in the reference implementation for how to interoperate with libdbus (that's what we had to do in GDBus to make it work on Win32).
(In reply to comment #29) > a) it only applies to the weird configuration where you are porting > a desktop environment to Windows (which in itself is a desktop > environent - go deeper). The current maintainer of D-Bus on Windows seems to be coming from KDE-on-Windows, in which each app or app bundle acts like its own little session: see Comment #20, Comment #27 for explanation of this. > b) you can achieve the same by just setting DBUS_SESSION_BUS_ADDRESS > in your desktop environment login script KDE-on-Windows seems to specifically avoid using Windows environment variables. I'm not sure whether they have the same semantics as Unix environment variables - they might be global, rather than only inherited parent-to-child. > c) even when running a DE, you want to run e.g. a 3rd party tool > (say, someone packaged up d-feet or gdbus.exe on Windows (latter > exists) to be able to easily connect to the session bus even > not built against the same "install-path" KDE-on-Windows is apparently specifically avoiding this (see prior comments). > - the D-Bus spec should be more precise concerning how autolaunch > works on Windows. E.g. the current paragraph, this one > > On start, the server opens a platform specific transport, > creates a mutex and a shared memory section containing the > related session bus address. This mutex will be inspected > by the dbus client library to detect a running dbus session > bus. The access to the mutex and the shared memory section > are protected by global locks. > > lacks important detail - it forces implementors to go look in > the reference implementation for how to interoperate with > libdbus (that's what we had to do in GDBus to make it work > on Win32). Yes, I would like this to be documented. It's not clear to me whether the current implementation of "autolaunch:" (with no arguments) is one-per-user or one-per-machine.
(In reply to comment #27) > In the end, DBus isn't really a first-class citizen on Windows: it's a "bring > your own bus" environment, so in all common cases, scope=*install-path seems to > be the right default. If two applications can agree to use the same DBus > library, then they'll probably expect to connect to the same bus by default as > well. Applications on Linux already have to cope with connecting to a message bus not having the features [1] they want and good applications do support this [2] - for example, you may be running a recent app on an old distro. Heck, if we didn't support this on Linux we would see a lot of complaints. I don't see why it should be any different on Windows. [1] : feature examples: - support for match rules such as arg[0, 1, 2, 3, ...]path - support for exchanging file descriptors (OK, unix specific but we could add a similar feature for Win32 HANDLEs) [2] : for example see: http://git.gnome.org/browse/glib/tree/gio/gdbusobjectmanagerclient.c?id=2.33.6#n1126
(In reply to comment #30) > > b) you can achieve the same by just setting DBUS_SESSION_BUS_ADDRESS > > in your desktop environment login script > > KDE-on-Windows seems to specifically avoid using Windows environment variables. > I'm not sure whether they have the same semantics as Unix environment variables > > - they might be global, rather than only inherited parent-to-child. > Well, in that case these applications (packaged as a whole) can use their own mechanism for storing / retrieving the bus address and use that when connecting to their own copy of the session message bus. But I still think it's busted since it doesn't allow any apps outside this whole to communicate with them; in a way, it's totally against what D-Bus was supposed to be: a way for applications to talk to one another. I don't think we should encourage that behavior by codifying it in the spec. That's why I want *install-path removed from the spec. > > c) even when running a DE, you want to run e.g. a 3rd party tool > > (say, someone packaged up d-feet or gdbus.exe on Windows (latter > > exists) to be able to easily connect to the session bus even > > not built against the same "install-path" > > KDE-on-Windows is apparently specifically avoiding this (see prior comments). I think it would be annoying, if I wasn't able to use any copy of d-feet or gdbus.exe to debug the app. I cannot see any good reason for not allowing this. > It's not clear to me whether the current implementation of "autolaunch:" (with > no arguments) is one-per-user or one-per-machine. I don't know either (I *think* it's one-per-user) but it should really be one-per-login session (just like we do on X11 today). Since it's not yet codified in the spec we can probably still change it.
(In reply to comment #27) > You can only count on a bus being present if you know that someone installed > DBus and created the bus -- and if you know that, then you can use their DBus > library, and then install-path will hook you up to their bus by default. I think the fundamental difference of opinion is: * I install KOffice (or Calligra or whatever it's called now). It comes with a copy of dbus-daemon.exe, because it can't rely on Windows to provide one. * I also install GIMP. It too comes with a copy of dbus-daemon.exe, for the same reasons. * I run KOffice's word processor, KOffice's spreadsheet, and GIMP. What happens? * Ralf and Jesper's version of events: each app attempts to connect to autolaunch:scope=*install-path. This spawns one instance of KOffice's copy of dbus-daemon.exe, to which both the word processor and the spreadsheet connect. It also spawns one instance of GIMP's copy of dbus-daemon.exe, to which GIMP connects. GIMP cannot communicate with either of the KOffice apps. * David's version of events: each app attempts to connect to autolaunch:. Whichever one I ran first spawns one instance of its "nearby" copy of dbus-daemon.exe. All three apps connect to that dbus-daemon. They can all communicate. David's version matches what would happen on Unix+X11 if you didn't already have a dbus-daemon running. Under normal circumstances, a modern Unix distribution will start a dbus-daemon during X session startup anyway, and if it doesn't, gnome-session or the KDE equivalent will - but if you're using twm under Linux From Scratch or something, autolaunch is still available, and it works like David's version of how Windows should work. > This also avoids potential issues with different DLL versions being installed > on the system I don't see how DLL versions are relevant? All versions of D-Bus since at least 1.0 interoperate, so you can connect to dbus-daemon 1.7 with libdbus 1.0, or vice versa. Processes communicating via D-Bus don't share a process space, so it's entirely valid for two peers to be using different versions of libdbus, or even an independent reimplementation like GDBus or ndesk-dbus. Something *install-path does provide is partial isolation between pseudo-sessions: if KOffice and GIMP each comes with a bundled copy of a different version of the same D-Bus service (something like gnome-keyring perhaps), and those bundled copies claim to be compatible (by having the same interface name, etc.) but are actually not, then you lose. My answer to this would tend to be "use namespacing correctly and be backwards-compatible, and you won't have that problem". > more liberal configure options might be > desirable With the patches from this bug applied, the default listening and connecting addresses are configurable. On Windows, you'd typically set them both to the same value. The default is "autolaunch:scope=*install-path" in those patches as written, although based on David's review on IRC I'm going to apply them with "autolaunch:" instead, since that interoperates with GDBus. In situations where install-path is preferred, you'd do: # Autotools ./configure \ --with-dbus-session-bus-connect-address=autolaunch:scope=*install-path \ --with-dbus-session-bus-listen-address=autolaunch:scope=*install-path # CMake cmake ./cmake \ -DDBUS_SESSION_BUS_CONNECT_ADDRESS=autolaunch:scope=*install-path \ -DDBUS_SESSION_BUS_LISTEN_ADDRESS=autolaunch:scope=*install-path On Unix, there's typically no need to change them at all, but if you do, the two values will have to be different. The defaults are equivalent to: # Autotools ./configure \ --with-dbus-session-bus-connect-address=autolaunch: \ --with-dbus-session-bus-listen-address=unix:tmpdir=/tmp # CMake cmake ./cmake \ -DDBUS_SESSION_BUS_CONNECT_ADDRESS=autolaunch: \ -DDBUS_SESSION_BUS_LISTEN_ADDRESS=unix:tmpdir=/tmp
(In reply to comment #8) > Created attachment 55129 [details] [review] > [2/3] cmake: use the same default system bus address as for autotools I applied this, based on review from davidz and lack of any veto here. Fixed in git for 1.7.0. (In reply to comment #17) > Created attachment 56880 [details] [review] > Split DBUS_SESSION_BUS_DEFAULT_ADDRESS into listen, connect addresses I applied this with the Windows defaults changed to "autolaunch:", based on review from davidz and lack of any veto here. Fixed in git for 1.7.0. The remaining thing here is that the default might change back to "autolaunch:scope=*install-path" if team GDBus are persuaded that that's better. This seems unlikely. The other possible resolution is deciding that "autolaunch:" is in fact correct, and closing this as WORKSFORME or something.
> (In reply to comment #17) > > Created attachment 56880 [details] [review] [review] > > Split DBUS_SESSION_BUS_DEFAULT_ADDRESS into listen, connect addresses > > I applied this with the Windows defaults changed to "autolaunch:", based on > review from davidz and lack of any veto here. Fixed in git for 1.7.0. full agree from my side.
(In reply to comment #30) > It's not clear to me whether the current implementation of "autolaunch:" (with > no arguments) is one-per-user or one-per-machine. From the code I would say one-per-machine for windows workstations. On Windows Terminal Servers this may be different, not sure yet.
(In reply to comment #32) > I don't know either (I *think* it's one-per-user) but it should really be > one-per-login session (just like we do on X11 today). +1 from me for a standalone dbus windows binary package, as distributed on unix. On windows it is important to understand the term "session", which differs to unix. A usefull explanation is located at http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/windows-nt-session.html
(In reply to comment #34) > The remaining thing here is that the default might change back to > "autolaunch:scope=*install-path" if team GDBus are persuaded that that's > better. I'm going to resolve this as WORKSFORME. If anyone feels particularly strongly that "autolaunch:" is the wrong default, they can open a new bug or reopen this one. (In reply to comment #37) > On windows it is important to understand the term "session", which differs > to unix. > A usefull explanation is located at http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/windows-nt-session.html Thanks, that page is a useful resource. I don't think a D-Bus session bus should be linked to one of the Object Manager sessions described on that page. The naming collision is unfortunate, but as that page explains, Object Manager sessions aren't login sessions: Fast User Switching switches between users within one (Object Manager) session, and multiple users certainly shouldn't share a D-Bus session bus. Of the concepts on that page, the LSA "logon session" looks like the closest to what we want? (The naming collision isn't limited to Windows, sadly. Unix also has several orthogonal things called "sessions" - D-Bus session buses don't map 1:1 to the session IDs related to setsid(), for instance.)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.