Please check the comment by Erwann http://defect.opensolaris.org/bz/show_bug.cgi?id=2980#c7, is that correct way to go?

I was unaware that the D-Bus port of GConf made it into a stable release.  For the most part it was a hack for the maemo and shouldn't be use unless there was some development there recently.  I don't see it running as a D-Bus service on my system.

Most likely the report is wrong.  There isn't much details other than there is an error and configuration is lost.  Does GEdit run?  It runs just fine for me though GnomeUI does complain:

 GnomeUI-WARNING **: While connecting to session manager:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.

That is absolutely because the user is trying to run as a different uid but still has the DBUS_SESSION_BUS_ADDRESS pointing to his own bus.  This is completely a security feature and not a bug.  Using `su -` is the correct way to log into a new session.  BTW by the above warning it is the session manager that can't be connected to.  The suggestion at http://defect.opensolaris.org/bz/show_bug.cgi?id=2980#c7 is correct except for the su suggestion is swapped.  The correct command is su - not su.

Closing as not a bug.

John: In the upstream code GConf uses DBus now just as a naming service to avoid multiple copies, but not yet for IPC.

Halton: Clearing the environment as Erwann suggested will probably work.  But I want to emphasize that having a different uid connect to your X session is not something we want to support.  The reason is that the other uid has *total control* over your X session, and therefore effectively can do anything it wants to programs running as your uid.  

If you are running gedit as another user to gain access to a file for example, I suggest using ACLs.  If you don't want the other programs to have access to your files etc. (i.e. you're running as a test user for sandboxing reasons), then the correct thing to do is to create a new login session as that user.

I agree that we shouldn't support allowing another user to connect, but this is only part of the issue, and I don't think closing this as not a bug is the right answer.

If this error occurs libgconf or libdbus should automatically start a local session bus so that the user isn't left unable to get any GConf settings (maybe this is not the case, but it's certainly the impression with the error being reported).

To not auto-start a session is essentially a regression over the prior behaviour.

Can pfexec be patched to clear the DBUS_SESSION_BUS_ADDRESS environment variable?  I believe libdbus will auto-spawn a bus for compatibility if it's not set.

The issue here is that we're getting permission denial; it would not be a trivial patch to libdbus to try connecting to a bus but then fall back after that instead of just noticing the environment variable isn't set.

Maybe a easier patch would put the uid in the environment variable; if it's not what we expect we ignore it.

Also do note the auto-spawning feature is really a terrible hack. If you run two different copies of gedit from two terminal tabs for example, you will get two session bus instances.  That in turn means two instances of gconfd, which will happily stomp over each other's files in ~/.gconf.  

In Fedora we are trying very hard to get rid of legacy usage of X applications running as root for this and a long list of other reasons.

I understand that unsetting the environment variable is a work-around, and it's looking like we will need to use for now, but it would seem to make sense that d-bus needs a way to auto-launch yet avoid lots of instances for the same user, I feel that this is going to become even more important if GConf is going to totally move to using D-Bus as it's IPC mechanism.

As I understand the way that d-bus locates it's service, it does one of the following:

1) Look for DBUS_SESSION_BUS_ADDRESS

2) Look for an XAtom

3) Look for address in a file in ${HOME}/.dbus/sessionbus

If we do auto launch then shouldn't we try to avoid that there is more than one for any given user, i.e. re-use an existing session if it exists?

I actually think that this is not unique to GConf, it's just that GConf is highlighting it now. 

On OpenSolaris we have to also contend with applications that get launched in a separate Zone, which is like a chroot environment but totally isolated all the way into the kernel - this presents issues too with apps that require D-Bus since Zones are not UI environments usually. 

Again, while we could spawn a specific session bus, in a zone there is no X, so we would rely upon environment variables and/or the file in ${HOME} to locate an existing session bus.

What do you think?

At the high level, the expectation is:

1 user id <-> 1 login session <-> 1 dbus-daemon instance <-> 1 X server

Any situation that deviates from this will at best cause weird behavior, at worst data loss or app failure.

Right now libdbus only looks for the DBUS_SESSION_BUS_ADDRESS variable.  We don't try to talk to the X server because we didn't want libdbus to strictly depend on libX among other reasons.  We don't use the filesystem because it will break in network $HOME situations.

I have a blog entry about this here:

http://cgwalters.livejournal.com/16885.html

> If we do auto launch then shouldn't we try to avoid that there is more than one
> for any given user, i.e. re-use an existing session if it exists?

I think that would make sense, but I don't see a good way to do it short of kernel support.  Note if we enforce this in libdbus, we should also enforce one X server per uid.

Zones I think we basically want to treat the same way as full virtualization, i.e. this is the same as if you wanted to connect to your session from a remote machine, and the answer there is vino.

Created attachment 19532 [details]
trace for gconf-editor

Debug with dbus code, internal_bus_get() fails with timeout error.

Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

There must some other scenarios could generate this error message. So it is no use to check whether DBUS_SESSION_BUS_ADDRESS is belong to app-run user. 

And from DBUS_SESSION_BUS_ADDRESS string itself, I do not see a way to get it's owner.

> > If we do auto launch then shouldn't we try to avoid that there is more than one
> > for any given user, i.e. re-use an existing session if it exists?
> 
> I think that would make sense, but I don't see a good way to do it short of
> kernel support.  Note if we enforce this in libdbus, we should also enforce one
> X server per uid.
> 
> Zones I think we basically want to treat the same way as full virtualization,
> i.e. this is the same as if you wanted to connect to your session from a remote
> machine, and the answer there is vino.

I tried with  'su -', dbus-daemon is added one more after each 'su -' and 'gconf-editor'. I guess avoiding dup dbus-daemon is a different problem. Should I report another bug?

Spawning a new bus when you get a security denial is not the right way to go. 
Having a UID embedded sounds like the sane way to do this.  If it isn't the
same UID treat it as if it is unset.  I don't know if this breaks the spec
though.  The check would be done in the unix socket transport layer and the
socket name editing would be in dbus-launch or somewhere in the bus/ directory.
 We have the guid= we could also have a sessionuid= part. Patches welcome (I
would look at the GUID code to get an idea of how to write this).

BTW while D-Bus is not tied to X dbus-launch is and will store the address in X
if an X connection is present when autolaunching a bus.

Also per user buses have been discussed at length and been rejected because of lifecycle issues.  Please read the archives on the mailing list.  If GConf needs to be per user it has to do that itself.

Created attachment 19543 [details] [review]
See comment.


I realize that the best way to fix this is probably to add the uid to the DBUS_SESSION_BUS_ADDRESS environment variable, as has been suggested.  However, we need to fix this issue in the short-term or else we will get a lot of people complaining about the regressions, and we only have a few days to get some sort of fix into the next release.

So, I patched GConf so that if the call to gconf_activate_server failed it would unset DBUS_SESSION_BUS_ADDRESS and try again.  However, this still failed with GConf complaining that it couldn't connect to the same temp file as specified by the environment variable before it was unset.  This confused me for a while.

I figured out that this is because D-Bus caches the bus_connection_addresses, and there doesn't seem to be any interface to uninitialize D-Bus so you can try again like I was trying to do in GConf.

The attached patch modifies internal_bus_get in dbus-bus.c so that if dbus_connection_open fails *and* if bus_connection-addresses was not initialized when the function was called, then it will uninitialize the bus_connection_addresses by calling addresses_shutdown_func.  This is, I'm sure, a hacky way to workaround the problem.  However, it does seem that D-Bus shouldn't cache the connection information if it fails to startup.  Otherwise, how can the calling program try again with different connection info?

Or, it might be better if D-Bus just offered a public interface to tell D-Bus that the calling program wants to try to start up D-Bus again a second time but with different connection information (e.g. by messing with unsetting DBUS_SESSION_BUS_ADDRESS or something), and that would just uninitialize things.
Then GConf could call that function before trying again.

While this doesn't really fix the problem as elegantly as fixing the environment variable to contain uid information, it does seem that D-Bus should offer an interface to allow calling programs to try again if they want (either by D-Bus automatically not caching on initial failure as this patch tries to do, or by providing a public interface to clear the cache).  So I think this issue should also be fixed regardless of how we fix the long-term issue of how to run programs which require GConf to run via su.

Thoughts?  Any suggestions on a better way to do this?

Created attachment 19544 [details] [review]
GConf patch for reference

For reference, here is the patch for GConf which solves the problem assuming the D-Bus patch in my last comment has also been applied.

Since people have suggested that this should be fixed in GConf, I also filed GConf bug #555745 so the GConf team can get involved.

   http://bugzilla.gnome.org/show_bug.cgi?id=555745

Brian - libdbus does offer such an interface: dbus_bus_get_private.  But again we really don't want apps trying to work around this.

I'll try to cook up a patch this weekend to have libdbus put the uid in DBUS_SESSION_BUS_ADDRESS and ignore it on mismatch.

Did you guys consider patching pfexec?

We should keep in mind the big picture too about how the desktop should work and interact with things like pfexec/su. As I mentioned, Fedora is driving towards a more PolicyKit-type setup for most things; I think it would make sense for OpenSolaris to push for a similar architecture if not PolicyKit itself.

One question to ask; DBUS_SESSION_BUS_ADDRESS is modeled on DISPLAY and our answer to "how should it work?" has always been "just like DISPLAY"; so, how do the X server and DISPLAY work in your setup? The Correct Fix is probably for dbus to work in exactly the same way.

This is also the answer for ssh forwarding, etc.

I'm not sure I get how this is a bug; if you have DBUS_SESSION_BUS_ADDRESS set to the wrong value, that is just like setting a DISPLAY that you can't connect to. Don't do that then. I can't quite tell from the comments, but I think using "su -" would fix the problem, wouldn't it? That's what should be done if switching to a random user.

I mean, either you want a new login session with its own dbus, i.e. don't want DBUS_SESSION_BUS_ADDRESS; or you want to share the old login session so want to forward DISPLAY and DBUS_SESSION_BUS_ADDRESS, *and* you want to ensure the new session has the right cookies to authorize to the old display and dbus-daemon.

But I don't see how it's possibly correct to create a situation where DBUS_SESSION_BUS_ADDRESS are forwarded to the new session, *and* no cookies and auth are set up, so they don't work. Either forward the env variables and make them work, or don't forward them. Right? What am I missing?

I think the issue is that XAuth and D-Bus auth are two different systems so where su'ing to another user will allow an app to run as that user on the primary user's display, D-Bus will prevent the app from connecting to the primary user's session bus.  

There are edge cases, however small, where the user wants to run an app using another user's configuration (for theming, permissions, remote access, etc.) but want to run on their display.  Since configuration in GNOME apps are starting to require D-Bus applications can fail to start up in this configuration.  G-Conf uses D-Bus to see if there are any other G-Conf instances in this session.

This is most likely a flaw in G-Conf but does in a round about way point to the issue of sessionless D-Bus requests, and what to do about them.  Right now we orphan autostarted busses.  

What I'm saying is basically that whenever xauth is forwarded to another user, the dbus auth needs to also be forwarded. These two should never be out of sync.

If not wanting to hack su or pam or whatever, one approach is to add an X-based auth mechanism to dbus (store a cookie on the X root window or something like that).

Adding crazy hacks here is probably going to end in tears. The only sane model is that the session is defined by dbus and X, and 1 bus goes with 1 X server ... 

an added problem with su - is that programs can't communicate. For example login as "work" and su - test -c thunderbird  results in tbird not being able to run the browser in response to a click on an url.

This is possible with su thunderbird.

This would seem to be another arguement for passing the session rather than dumping the inaccessible one and auto creating a new one.

My gut feeling is that there will be many such issues spouting from this well if it is implemented with hacky workarounds, as commented in #10 and #17 

I've changed my mind on this bug slightly - I'll now argue that what the session bus should be strongly tied to is $HOME, but the X server can vary.

(In reply to comment #17)
> What I'm saying is basically that whenever xauth is forwarded to another user,
> the dbus auth needs to also be forwarded. These two should never be out of
> sync.
> 
> If not wanting to hack su or pam or whatever, one approach is to add an X-based
> auth mechanism to dbus (store a cookie on the X root window or something like
> that).
> 
> Adding crazy hacks here is probably going to end in tears. The only sane model
> is that the session is defined by dbus and X, and 1 bus goes with 1 X server
> ... 

What I'd say is that's the most obvious and well defined model.  But let's consider what happens right now if you use "ssh -Y" to some server and run Firefox (and people do this).  What happens today is that Firefox is able to connect to your X server, but when Firefox tries to access DBUS_BUS_SESSION, none exists, so libdbus auto-spawns one.  This results in two session buses on two different machines, and one X server.

How *should* the ssh -Y case work?  Do we say "don't do that"?  Teach ssh how to forward dbus back to the local session? (Note this only works if running freedesktop on the client, if you're using one of those X-on-MS-Windows programs it will obviously fail.)

Now, I will argue that the ssh -Y use case is broken, and what we really want is something like VNC with client side fusion-type integration.  However - we can't actively break the legacy behavior here.  People expect "ssh -Y myserver firefox" to not break.

The other major case here is "sudo gedit", which is the original bug report.  Here again, people expect this to work; we can't just say "don't do that".  My suggestion is that we make this case match the ssh case by creating a second session bus (implemented by ignoring the existing DBUS_SESSION_BUS_ADDRESS because of a uid mismatch).

In both of these cases now, the session bus the application sees matches the machine $HOME is seen from, which I think is right.

One other thing I wanted to mention here is that for non-local applications, metacity actually suffixes their title with "(on $hostname)".  I think it should actually go further and have a differently-colored border to more strongly emphasize "This application is not local" with the implication that it may not behave as you might expect (for a variety of reasons, among them that it's not able to talk to the local session bus).

Similarly for applications run under sudo, especially for applications running as uid 0, metacity could draw e.g. a pulsing red border.  

While this may sound like crack at first, remember that essentially only sysadmins (or people acting under the direction of one) are going to end up in either of these situations, so having a weird border a good thing, since something weird is going on.

> Now, I will argue that the ssh -Y use case is broken, and what we really want
> is something like VNC with client side fusion-type integration.  However - we
> can't actively break the legacy behavior here.  People expect "ssh -Y myserver
> firefox" to not break.

There are two ways I can think of to keep it from breaking:
* add a dbus transport that tunnels over X protocol
* have ssh and su forward the dbus connection also

Anything else simply will break. Having two sessions connected to the same X server is not tractable for app developers and gnome developers to get right. There's no coherent semantic to it, since supposedly single-instance things become unpredictably multi-instance, and portions of the desktop you want to talk to become impossible to contact.

autolaunch produces undefined, incoherent, undocumentable behavior. Nobody can explain how to write an app or a per-session desktop daemon that works correctly in all cases if dbus-daemons are launched at random.

Failing actually fixing it (using the X tunnel idea or fixing ssh), my preference is not to autolaunch, but to force people to manually set DBUS_SESSION_BUS_ADDRESS _or_ manually launch dbus-daemon; i.e. make people actually figure out what's going on and deal with it. Then they'll at least understand exactly how it breaks. Autolaunch gives this sort of "well, I'll try to automatically work, but won't really, then fail mysteriously" sort of behavior.

There was a time when ssh and su did not magically handle X forwarding either, and people had to manually set up DISPLAY, and we liked it. In the snow, etc.

(In reply to comment #21)
>
> There are two ways I can think of to keep it from breaking:
> * add a dbus transport that tunnels over X protocol
> * have ssh and su forward the dbus connection also
> 
> Anything else simply will break. Having two sessions connected to the same X
> server is not tractable for app developers and gnome developers to get right.
> There's no coherent semantic to it, since supposedly single-instance things
> become unpredictably multi-instance, and portions of the desktop you want to
> talk to become impossible to contact.

Keep in mind unintended consequences.  

Let's say hypothetically that Firefox (correctly) grabbed a name on the session bus for uniqueness instead of using the X server as it does now.

If we turned on DBus forwarding over ssh when you specified -Y, then that would *break* the Firefox use case, because Firefox would now see the name on the session bus on the other machine, and just open the URL there and exit.  Thus, the sysadmin couldn't download that tarball of mediawiki they were trying to.

Here's another one - we recently changed GConf to use DBus to lookup the IOR for various reasons.  If we started forwarding the session bus, then all of a sudden "ssh -Y" launched apps would try to look up that IOR (something in /tmp) and *fail*, because obviously the CORBA socket is on a different machine.

I understand your original design was that the session bus matched the X server, but as I said before I've come to the perspective that there's a huge difference between X and DBus.

Namely, X is a display system.  Everything around it is focused on display.  Not that other things aren't wedged into it, but still.  DBus on the other hand is for *entirely arbitrary* things.  Preferences, power management, networking, etc.  If we change how the DBus scoping works it affects everything.  All DBus services have to be evaluated for behavior in this case.

A very common problem in all of these is going to be services which have an implicit dependency on a shared filesystem as well, as in the GConf case.  Think for example of a "recent files" service which has a method like org.freedesktop.Recent.GetRecent().  Obviously that's going to be in terms of local files, which anything remote can't access.

So going back to the 3 key things:

1) X server
2) DBus
3) Filesystem (really kernel, let's skip the NFS insanity for the moment)

2) and 3) are both essentially arbitrary protocols where anything can happen.  1) has always been about display.  

So my argument again is that the least confusing thing is that 1) is can vary, and 2) and 3) should come together.

The reason we don't just put the dbus socket as $HOME/.dbus to enforce this is simply to avoid breaking outright on NFS.  But NFS is an application problem, not something DBus can solve.

Fair points, some thinking out loud.

Examples where you want dbus-daemon and X server to go together
===

Say the session manager has a "logging out now, please save files" signal. You want everything on the X server to get that signal.

Or say you have a "suppress screensaver" API. You need every app on the X server to be using the same one of those.

Or basically everything in gnome-settings-daemon (theme, font, etc.) has to be singleton to the X server.

Shared NFS, separate sessions as same user
===

One thing I'm assuming is that there's a shared NFS homedir. If you are running as a different *user* on the remote system, then the right thing may be to have a separate session on that remote system.

Two sessions on one X server is kind of a mess and hard to make work right, but if you're going to say it's allowed, then yeah it's two different dbus-daemon.

I guess it's logical that if you can have two sessions for *different* users sharing an X server, then two sessions for the *same* user has to work also. A difference here is that if we prohibit two sessions for the *same* user sharing an X server, then we can say that each dbus-daemon on the same X server will have its own separate home directory. Which is at least something.

Gconf
===

> Here's another one - we recently changed GConf to use DBus to lookup the IOR
> for various reasons.  If we started forwarding the session bus, then all of a
> sudden "ssh -Y" launched apps would try to look up that IOR (something in /tmp)
> and *fail*, because obviously the CORBA socket is on a different machine.

Right, but this is just because gconf/CORBA are fucked up and not using dbus (you can, btw, enable tcp for orbit... not that it's advisable). If we weren't dealing with some nest of legacy corba crap, then what we'd want is that ssh -Y launched apps *do* use the original config daemon on the original machine - using dbus to locate that daemon and talk to it.

I'm OK with hacks to fix the legacy stuff, but not if they break doing it right eventually... so I think first you want the right way to work (that in fact you could share the config daemon for your whole session) and then second try to figure out some hack for this old gconf junk.

Firefox
===

> If we turned on DBus forwarding over ssh when you specified -Y, then that 
> would
> *break* the Firefox use case, because Firefox would now see the name on the
> session bus on the other machine, and just open the URL there and exit.  Thus,
> the sysadmin couldn't download that tarball of mediawiki they were trying to.

But sometimes what you want is that your existing firefox instance is used. Especially if the homedir is shared; then I can download the tarball from either machine and it's fine. But say I'm running email on one machine and firefox on the other, when I click a link in my email for it to do the right thing it has to open in firefox on the firefox machine.

Recent files
===

> A very common problem in all of these is going to be services which have an
> implicit dependency on a shared filesystem as well, as in the GConf case. 
> Think for example of a "recent files" service which has a method like
> org.freedesktop.Recent.GetRecent().  Obviously that's going to be in terms of
> local files, which anything remote can't access.

Unless you have an NFS home directory, in which case a recent files service being global to everything on the X server is correct.


Possible direction 1
===

Concept: every app has to be in some session, but sessions can share an X server

* A session can be for the same user or a separate user.

* Everything in a session must have the same homedir, dbus-daemon, and X server.

* Multiple sessions can share an X server.

* We try to keep only 1 session per home directory on each X server, though this is not strictly required

* everything on a dbus-daemon can assume it shares homedir and X server with everything else on that daemon

* There is some way to create a session on a remote system, and tell the remote app how to join it (probably by setting DISPLAY and DBUS_SESSION_BUS_ADDRESS)

* ssh default is to have the remote app join the existing session or error out "No session available; to create one, run xyz then run the app again using abc env variables" OR ssh default is to autolaunch a session in such a way that everything else on that machine will find it

* some session on the X server has to "claim" all the singleton X server stuff such as: screensaver; settings-daemon; other sessions probably have to communicate with this session via X server (in fact using dbus for these X-specific functions probably becomes broken)

* some session on the X server has to own login/logout ("uber session" "owner session" "master session"?)

* the owning session has to tell the others when logout is happening, etc. ... probably using dbus becomes wrong, we have to use X

Possible direction 2
===

Concept: every app on an X server must be in the same session

* A session can have multiple homedirs and users in it

* dbus-daemon singletons can't assume everything in the session shares the same homedir, only that they share the same dbus-daemon and X server; however, they can assume no other daemons or sessions are using the X server.

* in this direction, screensaver, settings-daemon, logout notification, etc. can be done with dbus, because we know there aren't other things using the X server on a different dbus daemon. While in the multi-sessions-per-X-server case, we really ought to throw all these things off dbus, or at least tunnel them through X.

* if you "su" in this direction, then the su'd app is basically running with the original users' stuff (settings, etc.) but not the original user's home directory. Same for running an app on a remote machine.

* A behavior here might be, you read root's email as root in a root-owned email app, but clicking links opens in your regular-user firefox rather than launching a firefox for root.

* this direction is more like the historical behavior - if you have X resources for configuration, for example, they would be used by all apps from any user, on the same X server. Or if you use an X-associated networked audio server. This approach is the "traditional" way X was intended to work a long time ago, I think.


Bottom line
===

I tend to think that either of these directions could work, and that right now the reality doesn't match either one, and the reality doesn't really quite work.

Which one is easier to get to from current reality? Which one is most useful to get to? I don't know.

Seems like to really untangle the mess here someone has to select and document one of these approaches (or some other coherent approach), and then start fixing the code that isn't compatible with the approach... 

In direction 1 for example, all those settings-daemon, screensaver, session manager, etc. thingies that assume they are the only user of the X server have to be fixed, and some communication among sessions sharing an X server is missing.

In direction 2, the ssh forwarding is missing, and there are lots of bugs with people assuming two apps in a session share a homedir.

A direction 3 could be that we make *no* guarantees; apps have to assume they don't share a homedir with other stuff on the bus (as in direction 2), *and* there are other sessions and buses sharing the X server (as in direction 1).
That sounds great except I'm not sure it's actually possible to implement a desktop environment or suite of apps that doesn't make any of those assumptions. Maybe it is.

here's an idea: every session has to have its own (potentially rootless) X server. So basically to have a separate session for root or on a remote machine you have to run either xephyr or vnc or vmware or xen or a rootless X server.

That would make it a lot easier to get apps right (at the expense of having to implement the rootless X server).

(In reply to comment #23)

> One thing I'm assuming is that there's a shared NFS homedir.

Not applicable in the two major cases of:

* ssh -Y sysadmin from laptop to server
* su -

I'm not saying there aren't cases where the homedir is shared, but there are important cases where it isn't.

Anyways a lot to think about here, let me just dump some random thoughts:

* Not a big fan of requiring a rootless X server; admittedly in reality for the next 10+ years we'll need X on the free desktop, there does exist a wayland future ideally

* NFS home directories are always going to be last-one-wins "eat my data please" semantics, unfixably broken

* One *huge* wrench in any plans we have when discussing making remoting scenarios better (ssh etc.) is the possibility of different versions of dbus/X/ssh.  In reality people are going to be running slow-releasing OSes like RHEL5 on servers for many years to come.  And developers/sysadmins are likely going to be running faster-releasing OSes on their laptops.  If for example we fix libgconf to be a special case in any way, that doesn't help because the machine-running-libgconf (client in X terms, RHEL5 server) isn't going to have it.

* In general, this kind of thing is always going to be broken in some way.  We have enough problems with the regular desktop case as is.  I think the focus should be on compatibility (don't break what worked before like "ssh -Y server firefox" to download stuff on the server), and flexibility (let apps make choices).

Anyways I'll try to evaluate your possible scenarios soon.

> In general, this kind of thing is always going to be broken in some way.

Agreed; the bottom line for me though is that we don't want to run around in circles. It's just like the old X clipboards stuff; app A worked around app B and app B worked around A at the same time, and then they were both broken again, and had to toggle back to work around the other, and then they were both broken again...

So if there's a tradeoff where scenario such-and-such works and some other one does not, there should be a document that just says: we've agreed to change ssh, X, dbus, distribution defaults, gconfd, apps, session manager, settings daemon, etc. to support such-and-such, and this other scenario abc we've agreed to not care about.

And then when the bug reports come in for abc that's been traded off and punted, we can just point to the writeup document and WONTFIX because we want to keep the such-and-such scenario working and that requires that abc does not work.

> I think the focus
> should be on compatibility (don't break what worked before like "ssh -Y server
> firefox" to download stuff on the server), and flexibility (let apps make
> choices).

"ssh -Y server firefox" more just happens to work ... it isn't really defined _why_ it works and what the desktop has to do to make it keep working. Picking the "why" for how it keeps working is what will determine which other scenarios work or break. In the short term, ssh -Y server firefox can probably keep working regardless, the question is what else breaks given the "why", or which desktop features firefox might start to rely on that might break "ssh -Y server firefox" inadvertently... gconf being a great example.

> * Not a big fan of requiring a rootless X server; admittedly in reality for
> the next 10+ years we'll need X on the free desktop, there does exist a
> wayland future ideally

Wayland could theoretically design-in a solution, who knows. The possible win of rootless X is that you could avoid any tricky stuff for apps to get right, and keep the app-visible model very simple (and virtualization-compatible...).
A second X server, whether nested or rootless, or VNC for that matter, is the direct analog of opening a new terminal session on a remote server. Opening just one app on an existing X session is kind of like running something on a remote server and having it be a job in your local shell. If that melts your mind, that's the problem created by letting "ssh -Y server firefox" work.

The big appeal I think is to be able to solve one problem (a nice way to open a nested display or VM) instead of fixing N apps.


Anyway, to stay on topic for dbus, re-reading the original bug topic...

You said only this can be expected to work reliably:
1 user id <-> 1 login session <-> 1 dbus-daemon instance <-> 1 X server

And I think that is pretty much the de facto situation, that's all that's going to work all the time without screwing around, because there's no agreed-upon way that anything else does work or doesn't. There's some real spec work and thinking to be done about other situations that could work. I think maybe they could, and maybe there are related dbus changes, but who knows what those changes are until someone documents how it all should work.

With dbus right now, 'ssh -Y server firefox' actually does work, doesn't it? I would expect it probably happens to work due to autolaunch, and not using any desktop services that assume they share an X server with the app (such as a screensaver inhibitor or single-instance app that really needs to be single-instance).

My take on the original bug is that "su -" instead of just "su" should be used; inappropriate env variables are getting forwarded. Then autolaunch will kick in and things should work fine.

I'm pretty uncomfortable autolaunching on a *bad* DBUS_SESSION_BUS_ADDRESS. The user set that address, whether accidentally or not; if it's broken there should be an error message, not silent launch of the wrong bus.

The "put uid in address" solution breaks the case where someone actually does want another user on their bus, which may (or may not) turn out to be a case we decide should work.

So I'd say the bottom line right now is: we kinda need that documentation of what will be supported and what won't, and in general how all the stuff (session-specific daemons, X-server-specific daemons, apps, dbus) is supposed to work together. I don't know that dbus bugzilla is the right forum to propose the answer on this. But once there's a document, we could come back here and implement the dbus portion of the answer.

In the meantime, I think the workaround is to unset the env var, for example using "su -" ... don't see much alternative.

Another possible solution is an X11 transport for dbus, btw. Which allows 1 X server to 1 dbus always, even without ssh or su changes.

The only trick at that point is that stuff on the same X server and dbus-daemon doesn't have to share a home directory.

I guess this is an implementation of "Possible direction 2" from comment 23, but without having to modify ssh or su.

"Possible direction 2" is the least amount of work to get to a solution that is reasonably well-defined and functional, perhaps. But it means killing off autolaunch...

This issue is also a blocker for D-Bus Accessibility.

I believe that the issue is EXACTLY the same as for a D-Bus based GConf, but I'll describe our issues just to make sure. 

1) Applications launched via "sudo <app>" or "su <user>; <app>" should be accessible.
2) Applications launched over ssh should be accessible.

Currently neither of these situations work with AT-SPI D-Bus. We are mainly worried about the "multi-user" case. This is very important as the "greeter" and the "gksudo" windows need to have access to the same D-Bus bus as the main user session and therefore to Orca and other ATs.

The ssh forwarding we can probably wait for / Is not so important.

Adding my two cents. What we imagine is necessary is a D-Bus bus that has the same authorizations and access as the X server. I won't try and defend it, but this was the situation in CORBA AT-SPI as the accessibility IOR was set on the root X window.

This issue is listed on the gnome a11y bonobo deprecation page 
http://live.gnome.org/Accessibility/BonoboDeprecation.

The issue is described as:

"""
UNASSIGNED/AT-RISK: With the AT-SPI/CORBA solution, assistive technologies can access GUIs that are not running as the user logged into the desktop. For example, they can access system administration GUIs running as root. There is currently no support in the GNOME D-Bus offering for this. There is a general consensus, however, that there should be an "X Session Bus" for all manners of things, including accessibility. The team needs to work with the larger GNOME/D-Bus community to help make this happen and then migrate the AT-SPI/D-Bus solution to use this newly created bus.
"""

Any progress here?

This issue makes "ssh $host $gnome_app" completely useless.  It has broken the most wonderful aspect of X11 (over ssh) which is remote application transparency.

Would have been nice if this was fixed for Gnome 2.28.  :-(

Have you tried "ssh -Y..." ?

BTW, here's what I'd propose:

http://lists.freedesktop.org/archives/dbus/2010-May/012853.html

I started a thread with a mail to try to summarize:
http://lists.freedesktop.org/archives/dbus/2010-May/012860.html

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/7.