registry team mailing list archive

[Bug Watch Updater <328575@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 33 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=17970.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2008-10-08T04:06:49+00:00 Halton Huo wrote:

Created an attachment (id=19484)
error log for gedit

This bug is actually from
http://defect.opensolaris.org/bz/show_bug.cgi?id=2980

How to reproduce
1) Create two users: work and test
2) Login as work
3) Open terminal, type su test(and password)
4) (In the same terminal), type gedit

Expected result:
  gedit lanched for user test without error
Actual result:
  gedit lanched for user test with error, the configuration for user test is lost

Now Gconf using dbus to communicate, this will cause apps will fail to
connect gconf under 'su <user>' environment. Please check the attachment
for gedit.

This bug can be reproduce on Ubuntu Intrepid and
OpenSolaris+vermillion_99, they all have latest gnome 2.23.92 or 2.24.0
installed.

It is critical for OpenSolaris, so mark it as high priority.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/0

------------------------------------------------------------------------
On 2008-10-08T04:11:19+00:00 Halton Huo wrote:

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

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/1

------------------------------------------------------------------------
On 2008-10-08T07:56:03+00:00 Johnp-redhat wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/2

------------------------------------------------------------------------
On 2008-10-08T10:22:03+00:00 Colin Walters wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/3

------------------------------------------------------------------------
On 2008-10-08T13:23:50+00:00 Dar wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/4

------------------------------------------------------------------------
On 2008-10-08T14:40:25+00:00 Colin Walters wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/5

------------------------------------------------------------------------
On 2008-10-08T15:06:42+00:00 Dar wrote:

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?

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/6

------------------------------------------------------------------------
On 2008-10-08T15:51:42+00:00 Colin Walters wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/7

------------------------------------------------------------------------
On 2008-10-09T05:30:38+00:00 Halton Huo wrote:

Created an attachment (id=19532)
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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/8

------------------------------------------------------------------------
On 2008-10-09T07:18:53+00:00 Halton Huo wrote:

> > 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?

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/9

------------------------------------------------------------------------
On 2008-10-09T08:09:08+00:00 Johnp-redhat wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/10

------------------------------------------------------------------------
On 2008-10-09T17:44:37+00:00 Brian-cameron-oracle wrote:

Created an attachment (id=19543)
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?

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/11

------------------------------------------------------------------------
On 2008-10-09T17:45:24+00:00 Brian-cameron-oracle wrote:

Created an attachment (id=19544)
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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/12

------------------------------------------------------------------------
On 2008-10-09T17:59:10+00:00 Brian-cameron-oracle wrote:


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

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/13

------------------------------------------------------------------------
On 2008-10-18T11:19:42+00:00 Colin Walters wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/14

------------------------------------------------------------------------
On 2008-10-19T10:10:35+00:00 Hp-pobox wrote:

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?

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/15

------------------------------------------------------------------------
On 2008-10-20T12:53:48+00:00 Johnp-redhat wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/16

------------------------------------------------------------------------
On 2008-10-20T19:47:15+00:00 Hp-pobox wrote:

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 ...

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/17

------------------------------------------------------------------------
On 2009-02-06T23:34:55+00:00 Freedy wrote:

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

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/18

------------------------------------------------------------------------
On 2009-02-10T10:01:24+00:00 Colin Walters wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/19

------------------------------------------------------------------------
On 2009-02-10T10:10:47+00:00 Colin Walters wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/20

------------------------------------------------------------------------
On 2009-03-31T18:08:58+00:00 Hp-pobox wrote:

> 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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/33

------------------------------------------------------------------------
On 2009-04-01T10:36:40+00:00 Colin Walters wrote:

(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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/34

------------------------------------------------------------------------
On 2009-04-01T15:34:48+00:00 Hp-pobox wrote:

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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/35

------------------------------------------------------------------------
On 2009-04-01T16:33:45+00:00 Hp-pobox wrote:

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).

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/36

------------------------------------------------------------------------
On 2009-04-17T13:25:24+00:00 Colin Walters wrote:

(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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/42

------------------------------------------------------------------------
On 2009-04-17T19:23:37+00:00 Hp-pobox wrote:

> 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.

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/44

------------------------------------------------------------------------
On 2009-04-17T19:29:29+00:00 Hp-pobox wrote:

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...

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/45

------------------------------------------------------------------------
On 2009-07-28T08:24:55+00:00 Mark-doffman-codethink wrote:

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.
"""

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/93

------------------------------------------------------------------------
On 2009-09-24T14:14:16+00:00 Brian J. Murrell wrote:

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.  :-(

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/103

------------------------------------------------------------------------
On 2009-09-25T00:13:24+00:00 Pacho Ramos wrote:

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

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/104

------------------------------------------------------------------------
On 2010-05-24T15:15:18+00:00 Lennart-poettering wrote:

BTW, here's what I'd propose:

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

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/106

------------------------------------------------------------------------
On 2010-05-25T12:30:16+00:00 Hp-pobox wrote:

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

Reply at: https://bugs.launchpad.net/dbus/+bug/328575/comments/107


** Changed in: dbus
   Importance: Unknown => Critical

** Bug watch added: defect.opensolaris.org/bz/ #2980
   http://defect.opensolaris.org/bz/show_bug.cgi?id=2980

-- 
[gnome-terminal SRU] Cannot start gnome-terminal (or x-terminal-emulator) because of gconf error
https://bugs.launchpad.net/bugs/328575
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for D-Bus.