After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 163132 - at-spi should expose all clients on user's DISPLAY
at-spi should expose all clients on user's DISPLAY
Product: at-spi
Classification: Platform
Component: registry
Other All
: Normal enhancement
: ---
Assigned To: Ariel Rios
: 154487 164941 164942 (view as bug list)
Depends on: 345428 345434
Blocks: 347124
Reported: 2005-01-06 15:43 UTC by George Kraft IV
Modified: 2007-02-14 07:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8

Original patches for at-spir IOR work. (2.85 KB, application/x-compressed-tar)
2006-06-20 14:25 UTC, Ariel Rios
New bridge code for preserving a11y login (2.05 KB, patch)
2006-07-10 19:34 UTC, Ariel Rios
none Details | Review
Cleaned at-spi patch (5.10 KB, patch)
2006-07-14 16:23 UTC, Ariel Rios
none Details | Review
Revised patch to sync with CVS HEAD (3.37 KB, patch)
2006-08-15 13:18 UTC, George Kraft IV
none Details | Review
Complete patch that includes bridge launching registry if user is gdm (5.33 KB, patch)
2006-09-25 21:14 UTC, Ariel Rios
none Details | Review
Remove launching of registry if user is gdm (5.11 KB, patch)
2006-10-03 20:56 UTC, Ariel Rios
needs-work Details | Review
attachment to remove gtk+/gdk dependencies from the bridge section of the code, and a couple of other cleanups. (8.18 KB, patch)
2006-10-16 15:03 UTC, bill.haneman
none Details | Review
patch improved to prevent fatal errors if bridge cannot find running registry. (10.29 KB, patch)
2006-10-16 16:13 UTC, bill.haneman
none Details | Review
Add Changelog (10.23 KB, patch)
2006-10-16 20:02 UTC, Ariel Rios
committed Details | Review
Prevent bridge to crash if registry was not found (1.42 KB, patch)
2006-12-07 18:55 UTC, Ariel Rios
committed Details | Review

Description George Kraft IV 2005-01-06 15:43:43 UTC
Please describe the problem:
When I run gnome-hello (:pserver:anonymous anoncvs gnome org:/cvs/gnome)
I see it listed by at-poke; however, if I "xhost +", su to a different
user in an xterm, and run gnome-hello, then I don't see it listed by
at-poke.  The at-spi is user/session sensitive.

Steps to reproduce:
1. cvs checkout gnome-hello, then build it
2. in an xterm: xhost +; su to a different user; run gnome-hello
3. run at-poke and look for gnome-hello in the application list

Actual results:
at-poke does not list gnome-hello as an application that can have its a11y
attributes queried.

Expected results:
gnome-hello has been X11 authenticated and is displayed to my screen; therefore,
I would expect that an assistive technology (screen reader) would be able to
detect and query the application.

Does this happen every time?

Other information:
Create a stringified reference ('Interoperable Object Reference': IOR), and
store in the Xserver's root window (atom).  This information stored in the
Xserver then can be used to rendezvous with the at-spi ORB by any application
that has successfully X11 authenticated.  This will change at-spi from being
user/session to X11 display centric.
Comment 1 bill.haneman 2005-01-06 15:53:55 UTC
As-stated, this isn't a bug.  But I agree that this is a valid RFE.  Thanks for
noting this issue George.  I'm amending the summary somewhat...
Comment 4 Calum Benson 2006-04-26 17:05:33 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 5 bill.haneman 2006-06-14 15:56:57 UTC
*** Bug 164942 has been marked as a duplicate of this bug. ***
Comment 6 bill.haneman 2006-06-14 15:57:27 UTC
*** Bug 164941 has been marked as a duplicate of this bug. ***
Comment 7 Ariel Rios 2006-06-20 14:24:32 UTC
Some info about what we have been discussing on email so we can get this rolling again. My original posts and patches:

"Basically the patches do the following:

-at-spi/registryd/registry-main.c: After creating the registry set the
IOR as an X property session attached to the main X root window.

-at-spi/bridge.c: The bridge now looks for this IOR for creating the
registry instead of using the oaf id. If the IOR is not present it
does not creates a new one and just complains. This avoids the problem
of having various instances of at-spi-registryd being loaded since we
only want one per session.

-gnome-session/gsm-at-startup.[ch]: We launch at-spi-registryd and
start the component very early in the session so all of the apps
looking for the IOR will find it. If for some reason when trying to
activate the registry we get an error we launch an error dialog and
quit the session.

Also, you need to set your root orbitrc file to this:

Comment 8 Ariel Rios 2006-06-20 14:25:58 UTC
Created attachment 67717 [details]
Original patches for at-spir IOR work.

Original patches for at-spir IOR work.
Comment 9 Ariel Rios 2006-06-20 14:40:12 UTC
I think the following selections contain the most interesting part of the ongoing email discussion:

Bill said:
> > However - it seems to me that the patches below will break accessible
> > login, unless we patch gdm to launch the registry before launching the
> > greeter.  (I have no problem with that, but the existing patches don't
> > account for it yet).

Michael said:
>       Nah - I guess if there is some gdm launch in advance then we'll get the
> same value in gnome-session too - ultimately the registry singleton
> registers itself with X - so, we should get no more problems there than
> currently.

Bill said:
The problem I am referring to is that gdm doesn't launch
at-spi-registryd directly; the greeter is launched first, _before_ any
AT client.  AT clients are only launched on-demand via user-defined
"gestures".  The current "accessible login" scenario relies on the fact
that the gdm greeter loads the atk-bridge gmodule, which launches the
registry automagically, before the AT clients.

So if we apply the proposed patches, gdm needs to be patched to launch
at-spi-registryd, and some boolean "use accessible login" option would
need to be added to the gdm.conf choices.  I suppose we should move the
loading of the atk-bridge and gail gmodules there too, instead of (as we
currently do) leveraging the existing gmodule load option of gdm.

After talking to Michael about this (in particular, the gdm regression
that it would entail), he suggested an alternative:

in bridge.c, look for the Xatom/IOR, as the current patch does;
if the IOR is not found, AND the env variable DESKTOP_SESSION != gnome,
then activate the registry as before.  If the gnome session env variable
is set, and the IOR is not found, then return NULL for the registry with
a g_critical error (as in the current patch).

This basically means both the old and new codepaths in bridge.c still
exist, but it means we don't have to make gdm at-spi-registry-aware.

Also, registry-main.c should have an g_at_exit hook that removes the X
atom, to make things cleaner and reduce the chances of getting a stale
Mark said:

In sunspeak, DESKTOP_SESSION isn't a stable interface. I'd prefer if
you didn't rely on that as no doubt it could disappear in the future.

       (If the issue is GDM, why doesn't it start the registry itself?)

Bill said:
Before making a final decision, it would be nice to test the result with
a multi-display use case too, i.e. log in twice as the same user, with
different DISPLAYs, and confirm that the sessions function
independently. I think that the existing code in registry-main.c, which
associates the registry with AT_SPI_DISPLAY, should enable this.   If
that works _and_ the XAtom IOR in bridge.c works (for xhost and for apps
run as root on the user's DISPLAY), then we'll really have achieved our
Comment 10 bill.haneman 2006-06-27 17:14:34 UTC
*** Bug 154487 has been marked as a duplicate of this bug. ***
Comment 11 bill.haneman 2006-06-29 11:02:53 UTC
ariel, can we get status on this bug?  Also I don't see any dependency bug for the gdm case yet.  Thanks!
Comment 12 Ariel Rios 2006-06-29 12:56:33 UTC
I created Bug 345434 for gdm and make it depend on Bug 163132. Maybe I should have done it the other way around. 
Comment 13 Ariel Rios 2006-07-10 19:34:20 UTC
Created attachment 68740 [details] [review]
New bridge code for preserving a11y login

I have been doing various work. I have worked on suggestions from Brian (bug 345434) about how to modify gdm. After working on that I found one sad thing about it. Even though I can launch at-spi-registryd still I need to start the component just as gnome-session does that. However, I don't think adding bonobo code to gdm is something nice. So I ended doing something suggested at some point in the thread. On bridge.c I added an else if looking if useris gdm then do whatever we did before (that is initializing the component and thus launching at-spi-registryd). 

A11y login works exactly the same as it used too and the IOR helps with the actual problem of this bug. Saying so everybody is happy especially since gnome 2.16 freeze is near and having this work will help a lot of people.

Comment 14 bill.haneman 2006-07-11 17:16:01 UTC
Ariel: I don't understand why gdm would need to use bonobo at all in order to launch at-spi-registryd; whenever at-spi-registryd is launched, it registers itself as a bonobo service automatically.  Thus, I don't understand your point about "adding bonobo code to gdm", nor what you mean by "I need to start the component just as gnome-session does"...

Comment 15 bill.haneman 2006-07-12 15:26:28 UTC
Comment on attachment 67717 [details]
Original patches for at-spir IOR work.

Ariel, in the gnome-session portion of this patch, the function gsm_assistive_tech_start() seems to be unnecessary.  Just executing the at-spi-registryd is all that should be necessary in order to ensure that the AT-SPI Registry service exists.  Thus the libbonobo.h dependency doesn't seem to be necessary.  See also my comment above regarding the gdm patch.
Comment 16 Ariel Rios 2006-07-14 16:23:32 UTC
Created attachment 68935 [details] [review]
Cleaned at-spi patch

So this patch is very similar to the at-spi part of the first tarball. Please look for the gdm and gnome-session bugs for corresponding patches. During the rest of the day I will be doing more testing to ensure everything is right. I wait for your comments. Still need to add Changelogs for all of this.
Comment 17 bill.haneman 2006-07-18 15:28:32 UTC
I just changed this bug to depend on the gdm and gnome-session bugs, which I think is the right dependency order.  However the gnome-session bug probably also depends on this one, since it presumes that the bridge will set the XAtom/IOR on the root window.

The patch attached to this bug looks correct to me, please commit when the gnome-session patch is ready and approved.  The gdm patch should go in then as well, though possibly it would be OK to use the "activate if userid==gdm" fallback if the gdm work isn't ready in time, as a stopgap measure.
Comment 18 Al Puzzuoli 2006-07-22 16:37:24 UTC
Is this ready for testing yet?  As a user and trainer of Assistive technology myself, I eagerly await its implementation, and would be happy to contribute in any way possible to help it along.  Until issues surrounding the use of administration tools are dealt with, we won't have fully independent access to the desktop, so resolving this one will be a major step, and a great feature add to Gnome 2.16.

Comment 19 George Kraft IV 2006-08-15 13:18:20 UTC
Created attachment 70943 [details] [review]
Revised patch to sync with CVS HEAD

The previous patch now conflicts with the patch from bug 336144.  This is a revised patch to sync with CVS HEAD.
Comment 20 George Kraft IV 2006-08-16 13:09:51 UTC
Please delete my patch from comment 19, because it belongs to the gnome-session dependency of this defect.
Comment 21 Willie Walker 2006-08-16 13:49:05 UTC
Hi George:  

I think this functionality is VERY IMPORTANT and I applaud the effort being done here.  I also support getting it in GNOME after it has been well tested and has had a chance to soak for a while.  Unfortunately, I don't think the schedule gives time for proper testing or soaking for GNOME 2.16, and I hesitate to see anyone commit anything that may introduce a regression so late in the release cycle.

If I understand correctly, the primary motivator for this work is so that users can access system adminstrator applications on the desktop.  I propose that for GNOME 2.16, the user has a workaround, albeit extremely inconvenient and clunky: log out and log back in as root.  

Coming from the user-centered-design camp, logging out/in is not the model I'd prefer, but I'd rather see *something* work than have accessibility potentially completely broken for the entire desktop.  Note that my use of "potentially completely broken" is not to be taken as an offense to the people submitting the patches for this work - it's merely a statement of my concern for the high risk of making such a change so late in the release cycle.  The patches may indeed be perfect, but I don't feel comfortable seeing them go into GNOME 2.16 without more testing and soaking.

As soon as GNOME 2.17 (or even possibly GNOME 2.16.1) opens, however, I think this work should be revisited and made a priority.

Thank you for your work here,

Comment 22 Daniel Holbach 2006-09-06 15:48:20 UTC
Marked patch from comment 19 as obsolete (according to comment 20), as it's attached to bug 345428 already.
Comment 23 Ariel Rios 2006-09-25 21:14:19 UTC
Created attachment 73396 [details] [review]
Complete patch that includes bridge launching registry if user is gdm

Since it looks as there is no good way to make gdm launch the registry (see gdm bug we let the bridge start the registry if the user is gdm. In this case we preserve a11y login and make use of the IOR as desired for all other users. If a patch for the gdm bug is done somehow then use patch 68935.
Comment 24 Brian Cameron 2006-09-26 20:02:48 UTC
Note that the user that GDM runs as is configurable and is specified in daemon/User.  Normally the username is "gdm" so if you hardcode this value it will work unless the user (or distro) has changed the configuration.

You can get the configured GDM user by running:

  gdmflexiserver --command="GET_CONFIG daemon/User"

It should respond:

"OK username"

FYI daemon/Group is the configurable GDM group name.

You don't have to get the info this way.  Note that gnome-session (in gnome-session-gdm-logout-action.[ch] attaches to the GDM socket directly (just as gdmflexiserver does) and gets the information directly from the socket rather than calling gdmflexiserver in a separate process to get the info.  This is probably a bit faster, though gdmflexiserver isn't too slow.
Comment 25 Brian Cameron 2006-09-26 20:04:01 UTC
I am reopening this bug because I notice that the patch as applied hardcodes the username to gdm, and it probably should not.  Probably should get the username via the above interface.
Comment 26 Brian Cameron 2006-09-26 20:09:26 UTC

Perhaps rather than checking the username, it would be best to check an environment variable.  Note that GDM sets the RUNNING_UNDER_GDM and GDM_VERSION environment variables so that various GDM gui's know if they were started by the 
GDM daemon.  These envvars are not propegated to the user's session that gets
started via GDM.

If it needs to be hardcoded in the bridge for some reason, then probably better if it can be configured or modified (perhaps via envvar).
Comment 27 bill.haneman 2006-09-26 20:46:28 UTC
I thought we were already advised NOT to use env vars?  Perhaps in another context, but we were advised for instance not to use DESKTOP_SESSION or similar, when deciding what logic the bridge should use.

I still think we should have gdm explicitly start at-spi-registryd.  There's no reason why it can't use the same technique as in the gnome-session patch, to wait for the XAtom to be set before proceeding (thus avoiding the race condition). Basically it's the same problem as for gnome-session...
Comment 28 Ariel Rios 2006-10-03 20:56:05 UTC
Created attachment 73972 [details] [review]
Remove launching of registry if user is gdm

Remove launching of registry if user is gdm.
Comment 29 bill.haneman 2006-10-16 10:46:39 UTC
The dependency on gdk is bad; we should remove that. Replacing the GDK_ROOT_WINDOW() call is probably sufficient to solve that problem in bridge.c; we then need to get rid of gdk_atom_intern and gdk_property_change in registry-main.c

Comment 30 bill.haneman 2006-10-16 12:37:25 UTC
Comment on attachment 73972 [details] [review]
Remove launching of registry if user is gdm

>RCS file: /cvs/gnome/at-spi/,v
>retrieving revision 1.190
>diff -u -r1.190
>---	22 Aug 2006 15:06:41 -0000	1.190
>+++	3 Oct 2006 20:54:21 -0000
>@@ -110,7 +110,8 @@
> 	libbonobo-2.0	>= req_ver_libbonobo
> 	atk		>= req_ver_atk
>+	gtk+-2.0	>= req_ver_gtk

Would prefer to avoid this (gtk dependency)...

>Index: atk-bridge/bridge.c
>RCS file: /cvs/gnome/at-spi/atk-bridge/bridge.c,v
>retrieving revision 1.95
>diff -u -r1.95 bridge.c
>--- atk-bridge/bridge.c	22 Aug 2006 14:57:50 -0000	1.95
>+++ atk-bridge/bridge.c	3 Oct 2006 20:54:21 -0000
>@@ -28,6 +28,8 @@
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdarg.h>
>+#include <gdk/gdk.h>
>+#include <gdk/gdkx.h>

>@@ -327,10 +330,37 @@

>+static gchar *
>+spi_atk_bridge_get_registry_ior (void)
>+     Atom AT_SPI_IOR = XInternAtom (GDK_DISPLAY(), "AT_SPI_IOR", False); 

Would prefer 
display = XOpenDisplay (spi_display_name);
if (display)
   AT_SPI_IOR = XInternAtom (display, "AT_SPI_IOR", False);

>+     Atom actual_type;
>+     int actual_format;
>+     unsigned char *data = NULL;  
>+     unsigned long nitems;
>+     unsigned long leftover;
>+     XGetWindowProperty(GDK_DISPLAY (), GDK_ROOT_WINDOW (), AT_SPI_IOR, 0L, 
>+			(long)BUFSIZ, False, 
>+			(Atom) 31, &actual_type, &actual_format,
>+			&nitems, &leftover, &data);

XGetWindowProperty (display, XRootWindowOfScreen (XDefaultScreen (display)),           
                    AT_SPI_IOR, OL,

and in registry-main.c:

>+static void
>+registry_set_ior (SpiRegistry *registry){
>+  CORBA_Environment ev;
>+  GdkAtom  AT_SPI_IOR = gdk_atom_intern ("AT_SPI_IOR", FALSE);
>+  char *name = NULL;
>+  CORBA_exception_init (&ev);
>+  name = CORBA_ORB_object_to_string (bonobo_activation_orb_get (),
>+                                     bonobo_object_corba_objref (bonobo_object (registry)),
>+                                     &ev);
>+  gdk_property_change (gdk_get_default_root_window (),
>+                       AT_SPI_IOR, (GdkAtom) 31, 8,
>+                       GDK_PROP_MODE_REPLACE,
>+                       (unsigned char *) name,
>+                       name ? strlen (name) : 0);

Why not (making AT_SPI_IOR an XAtom instead of a GdkAtom...)

XChangeProperty (spi_get_display (), 
                 XRootWindowOfScreen (XDefaultScreen (spi_get_display ())),
                 AT_SPI_IOR, ... 

Comment 31 bill.haneman 2006-10-16 13:31:57 UTC
I also notice that in spi_atk_bridge_get_registry, we're still using bonobo-activation to restart the registry if it dies.  I don't think this is correct - it will not work properly for remote apps.  The logic for restarting a defunct/dead registry should be the same as used by other apps (session, etc.) So the patches above are incomplete.

In light og this, when the new logic for registry activation is put in place, we should be able to remove all bonobo-activation dependencies from atk-bridge, with the possible exception of the "don't register bonobo embedded components" logic in atk_bridge_init.  (Not sure how to replace that logic yet).
Comment 32 bill.haneman 2006-10-16 13:38:39 UTC
Correction - I said:

" we're still using
bonobo-activation to restart the registry if it dies."

On closer examination this doesn't seem to be true; but there was indeed some spurious bonobo-activation code remaining (setting the AT_SPI_DISPLAY attribute for the activated object, which is no longer appropriate).  I am reworking the patch to account for the above issues and will post a new version.
Comment 33 bill.haneman 2006-10-16 15:03:17 UTC
Created attachment 74816 [details] [review]
attachment to remove gtk+/gdk dependencies from the bridge section of the code, and a couple of other cleanups.

This patch needs a ChangeLog entry.  Ariel, do you want to write it, or shall I?

It also needs to be tested in your environment/against your test cases.  Ariel and/or George, if you can test today and confirm that all is OK, I will roll into the tarball for gnome 2.17.1.
Comment 34 Ariel Rios 2006-10-16 15:08:25 UTC
I'll test i today and write the Changelog

Comment 35 bill.haneman 2006-10-16 15:09:30 UTC
"I will roll
into the tarball for gnome 2.17.1." ==> (If/when the gnome-session patch is accepted)
Comment 36 bill.haneman 2006-10-16 16:13:38 UTC
Created attachment 74825 [details] [review]
patch improved to prevent fatal errors if bridge cannot find running registry.

The additions to this patch eliminate the need for 'reset' behavior in the gnome-session patch, so the 'accessibility' gconf key can be left as-is regardless of whether the registry activation succeeds or fails, in gnome-session.
Comment 37 Ariel Rios 2006-10-16 20:02:31 UTC
Created attachment 74838 [details] [review]
Add Changelog

Changelog added.
Tested your patch and works nice.
Comment 38 bill.haneman 2006-11-07 00:32:41 UTC
Fixed in CVS; thanks all!
Comment 39 Al Puzzuoli 2006-11-08 16:40:17 UTC

Could someone outline what the best procedure would be for testing this?  I checked out and built gdm2, gnome-session, atk and gail.  I did this on a Ubuntu Edgy box.  The end result is that I am no longer able to login and get a usable desktop.  I  get a login prompt, but after entering my username and password, I'm dumped to what looks like a terminal prompt without a cursor.   Are some of the Ubuntu specific configuration files being overwritten or what?

Comment 40 Ariel Rios 2006-11-08 21:11:29 UTC
If you contact me I can help you with this. I don't think I touched any ubuntu conf but I can look with you. If you email me we can look over it.

Comment 41 Al Puzzuoli 2006-11-09 05:15:00 UTC
After some poking around with the assistance of Joanie Diggs, it turns out that my login issue was due to the fact that I hadn't pulled the latest at-spi.  The good news is that after updating at-spi, I am again able to get logged in; However, the bad news is that Orca still doesn't seem to be getting info from applications started via sudo.   I'm not sure yet, whether this is due to further issues with the infrastructure, or with Orca itself. 
Comment 42 Ariel Rios 2006-11-09 06:39:58 UTC
It looks like you need to:

Also, you need to set your root orbitrc file to this:

(from comment #7)

I assume that orca is working with the "normal" user but not with an app as root. Try doing the above and that should do the trick

Comment 43 Al Puzzuoli 2006-11-09 18:56:15 UTC

Adding those lines to .orbitrc did the trick!
after some initial testing, here are a few observations:
1.  Whenever I log in, I now get errors related to the gnome settings daemon.  I can close the dialog and after doing so, half the time, things work as expected, with focus going to the desktop, and other times, I lose speech altogether, not sure if Orca is hanging, the desktop is crashing or what.  2.Applications requiring sudo appear to be accessible if run from gnome-terminal.  For example, if I type:
sudo synaptic, and then enter my password, Synaptic launches, and Orca reads the application as expected.  However, if I run synaptic from the Gnome menu, I get the password dialog.  I enter my password, and then the synaptic window comes up; but, orca does not track this window, and is apparently left in a strange state.  if I exit synaptic using Alt-f4, Orca announces that focus has returned to the desktop, and then I get no more speech, although the Orca process itself is still running.  

I'm not sure whether the above symptoms are issues in the accessibility  infrastructure or with Orca itself.
Comment 44 George Kraft IV 2006-11-09 19:17:19 UTC
Al, are you able to accessibly dectect menu launched applications using at-poke?
Comment 45 Al Puzzuoli 2006-11-09 19:54:51 UTC
Hi George,

Since at-poke itself is inaccessible, I'm afraid I can't be much help here.  Is anyone else testing this yet who could help out?
Comment 46 bill.haneman 2006-11-10 01:15:18 UTC
Hi Al:

at-poke is inaccessible only to avoid self-referential loops - fundamentally it could/should be accessible because it's built with stock widgets.

My guess is that the problem you are seeing with menu-launched root apps is due to their not having the correct environment variables set for accessibility.  It's possible that enabling assistive technology support in your root desktop account settings would fix this for you, or it could be some other gnome-session bug.
Comment 47 Al Puzzuoli 2006-11-10 16:06:54 UTC
Hi Bill,

I do have accessibility  enabled in my root account, because I use it regularly for gui based system administration.

On another note just to clarify, should the changes to the .orbitrc file be made in the account of the regular user, or in the root account?  it seems to me that the change needs to be made in root and if so, then we're dealing with a bit of a circular dilemma in that any user relying on assistive technology to access the gui won't be able to make this change in the first place.

Comment 48 George Kraft IV 2006-11-10 16:44:11 UTC
Should this be globally set in /etc/orbitrc?
Comment 49 Ariel Rios 2006-11-10 16:47:45 UTC
If you set it globally it won't work. YOu need to have 
as root (and also as any other user you might need to switch to)
Your normal user should not have this setted. It might be a Orbit problem or enhancement.

Comment 50 bill.haneman 2006-11-10 17:52:23 UTC
It doesn't strike me as a bug, just a requirement.  The ORBIIOP settings are more restrictive than this by default, for security reasons.  

Are you sure it is necessary to set ORBIIOPUNIX=0?  That would seem to be a serious performance problem; the ORBs need to be able to attempt local unix domain sockets and fall back to the GIOP-over-IP method if that fails.

Al, I think this is just something that needs to be documented in the Accessibility Guide, as the similar ORBIIOP settings required to make Java apps accessible are documented (I believe).  The setting can be changed either via non-graphical console access (which many users will have via brltty) or from a gnome-terminal, using "su".  Either of those methods should work for bootstrapping, since a locally-owned gnome-terminal is still accessible if you switch to root in it using 'su'.

Ariel, I am surprised that you say setting this globally won't work.  I am pretty sure the /etc/orbitrc file is supposed to be the global setting which works unless specifically overridden in a user file.  Are you sure there was no .orbitrc in root's home when you were testing?


Comment 51 Willie Walker 2006-11-27 22:12:39 UTC
I'm having a miserable time testing this new code.  It seems to trash my Ubuntu Edgy GNOME environment whenever I attempt to build/install the various components that need it.  Has anyone had any success in making it work (I'm assuming so, otherwise it never would have been checked in, right)?  In addition, is it possible that this might have been closed as FIXED too soon?

On a related note, gksu has a feature where it grabs the keyboard by default.  This wreaks havoc with assistive technologies such as Orca, and you can disable this feature for your login session by running the following command:

gconftool-2 --type bool --set /apps/gksu/disable-grab "true"
Comment 52 Ariel Rios 2006-11-28 06:32:51 UTC

I checked the code on my Fedora Core 5. Are you getting some specific error? How are you building on Edgy? If you give me some more info I can start looking on getting it to work on edgy.

Comment 53 Daniel Holbach 2006-11-28 08:25:32 UTC
Please check bug 377079, which is related to this commit.
Comment 54 Willie Walker 2006-11-28 13:51:05 UTC
> I checked the code on my Fedora Core 5. Are you getting some specific error?
> How are you building on Edgy? If you give me some more info I can start looking
> on getting it to work on edgy.

I grabbed the following components from GNOME CVS HEAD and did a "./ --prefix=/usr; make; sudo make install" in each of them:  atk, gail, at-spi, gnome-session, and gdm2.

After I did this, I lose all sense of Ubuntu branding on the login screen and session (probably to be expected), and things went plain awry in my session.  My symptoms seem similar to what Al was seeing in, though he seems to be getting a bit further than I can get.

If you have the luxury of time to qualify the patch on a Ubuntu system, it would be great.
Comment 55 Daniel Holbach 2006-11-28 14:51:38 UTC
If you want to install the feisty version of the packages mentioned above, you could try the following:

# get backup packages
mkdir backup; cd backup; aptitude download libatk1.0-dev libatk1.0-doc libatk1.0-dbg libatk1.0-udeb libatk1.0-0 libatk1.0-data libgail-dbg libgail-dev libgail18 libgail-doc libgail-common libatspi-dbg libatspi1.0-0 libatspi-dev at-spi at-spi-doc gnome-session gdm; cd ..

# get some tools
sudo apt-get install devscripts dpkg-dev fakeroot

# get build-dependencies for the packages
sudo apt-get build-dep atk1.0 gail at-spi gnome-session gdm

# add the following line to /etc/apt/sources.list
deb-src feisty main restricted universe multiverse
sudo apt-get update

# do the actual build:
mkdir feisty; cd feisty; fakeroot apt-get source -b atk1.0 gail at-spi gnome-session gdm

Once this finishes you should have the current feisty packages ready for testing and you can install them with    sudo dpkg -i *.deb   (to roll back install the packages from backup/).

If you need any assistance with that, feel free to mail me.
Comment 56 Ariel Rios 2006-11-28 14:59:41 UTC
Ok I am going to install ubuntu and try Daniel's instructions so we can have a similar environment to test.

Comment 57 Ariel Rios 2006-12-07 18:55:11 UTC
Created attachment 77914 [details] [review]
Prevent bridge to crash if registry was not found

If for some reason we end without a registry we don'twant things to start crashing. Patch 74825 prevented some of this crashes but it looks like they are still happening on ubuntu. Applying this patch solves the problem.
Comment 58 Daniel Holbach 2006-12-13 16:15:12 UTC
Thanks Ariel - I uploaded the patch to Ubuntu Feisty today, let's see if it fixes the problem for everybody.
Comment 59 Mike Pedersen 2007-01-12 21:52:43 UTC
I'd just like to thank all those who have worked on this.  I've just been doing some work with the latest Orca, gnome 2.17 and ubuntu feisty and this really makes both installing the OS and using administrative apps so much easier.  Note to anyone trying this as well as those packaging distributions.  In order for this to work out of the box it seems as though you do need to create a .orbitrc file in your root directory which contains the following: 
I realize that this has been mentioned earlier in the bug but just wanted to leave the reminder now that this functionality is now useful to the community.  
thanks again
Comment 60 Michael Meeks 2007-01-15 09:50:26 UTC
If you change your ~/.orbitrc like that you open a potentially serious security hole on your machine. [ Of course, no exploits are known, and it has been audited in the past but ... ].

There is also no particular reason why this should be so IMHO; however - we rather need to get some strace -f logs of the server-side pieces to see why they can't connect (as root) to the user-owned client unix domain socket ?

Ariel - you need to analyse the strace -f output carefully, in conjunction with the ORBit2/linc2/src/linc-connection.c code [ AFAIR ].
Comment 61 George Kraft IV 2007-01-15 19:17:31 UTC
Michael, I see the Linux From Scrath folks are also setting RBIIOPIPv4=1 for the Java Access Bridge.  Is this a general problem/mis-understanding?
Comment 62 bill.haneman 2007-01-15 19:34:45 UTC
It's absolutely necessary when using the java access bridge.

No security issue has actually been identified, as Michael acknowledges.  You'd have to spoof/crack the ORBit IOR for the registry, or access the Xserver, to exploit.  An xserver exploit is a problem any way you look at it, so I don't really think this is such a live issue.
Comment 63 George Kraft IV 2007-01-15 21:21:14 UTC
Should these environment variables be glocally set in /etc/profile.d/ for atk-bridge and the java-access-bridge?
Comment 64 Al Puzzuoli 2007-01-16 00:50:43 UTC
We obviously don't want security holes; but, enabling these settings by default, or making them easily activated  via the GUI by a user with normal privs would have a significant practical impact in terms of  accessibility.  As it stands right now, the need to create the .orbitrc under the root account sets up a paradox that could  prove confusing for a typical new user who wouldn't necessarily be comfortable working in the console.
Also, having this turned on by default would mean immediate access to administrative tools on live cds, such as Ubuntu's installer.
Comment 65 Michael Meeks 2007-01-16 09:25:04 UTC
And of course, security-wise we only accept connections from the localhost - which should eliminate remote attacks.
Al - as you say, this is necessary for Java a11y, due to the JavaORB not using the ORBit2 Unix Domain Socket profile - fair enough, Sun also ships with it on.
We do not [ having ported to use a native bridge ].
Comment 66 Al Puzzuoli 2007-01-18 14:00:33 UTC
Is there any reason why this fix might not work on a system upgraded from Edgy?
Until now, I've always tested on clean Feisty installs.  but I just upgraded an Edgy box.  All the updates seemed to go fine, and I put the .orbitrc in root's home; However, the fix doesn't seem to be working.

Please let me know if there is any further information I can provide that would help troubleshoot.
Comment 67 bill.haneman 2007-01-18 14:06:29 UTC
Al - you may need to enable assistive technology support for the root user's account.  Log in as root and use the AT support preferences dialog, or
su to root and set the gconf key for root using gconftool-2.
Comment 68 Al Puzzuoli 2007-01-18 14:11:40 UTC
hi Bill,

Not sure if this is relevant, but until upgrading, I had actually been using the root account for all my administrative stuff, so I know that accessibility is already enabled.  But, could enabling the root account have broken things for some bizarre reason?  I don't see how, but then again, that's why I brought this up.
Comment 69 Joanmarie Diggs (IRC: joanie) 2007-01-27 23:55:08 UTC
Is there any chance that this patch would interfere with gnome-panel applet events?  Please see bug #400709.  Thanks!!
Comment 70 bill.haneman 2007-01-28 00:47:46 UTC
Hi Joanmarie - pretty sure not related - the gnome-panel problem looks like a configuration failure - all necessary gtk-modules don't seem to be getting found.  Perhaps the system in question lacks libgail-gnome?
Comment 71 Joanmarie Diggs (IRC: joanie) 2007-01-28 00:59:24 UTC
Hi Bill.  Thanks for the quick response!  The system in question has libgail-gnome.  Other thoughts/ideas?
Comment 72 Henrik Nilsen Omma 2007-02-07 22:08:30 UTC
I can confirm that simply setting:

in root's .orbitrc on Feisty now makes everything work nicely (yay!)

Unfortunately that's not something we can ship as a default in Ubuntu. We can ask users to create that file as a workaround, but that's still an incomplete solution.

IMO, the bug status should be set back to open until this can be resolved in code (unless this is an Ubuntu-specific problem of course).  
Comment 73 Li Yuan 2007-02-08 05:35:52 UTC
Just tried this on Ubuntu.
If I start Orca first and then start some gksu applications (like synaptic), everything is OK.
But if I start synaptic first and then start orca, orca will hang. And I think the problem is at-spi-registryd is hanging at that time. registryd calls bonobo_object_dup_ref and the function never returns. I am not sure, the bonobo's problem?

registryd's trace is:
  • #0 ??
    from /lib/
  • #1 poll
    from /lib/tls/i686/cmov/
  • #2 ??
    from /usr/lib/
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 ??
  • #7 ??
  • #8 ??
    from /usr/lib/
  • #9 ??
    from /usr/lib/
  • #10 ??
  • #11 ??
  • #12 ??
  • #13 ??
  • #14 ??
  • #15 ??
    from /lib/tls/i686/cmov/
  • #16 ??
    from /lib/tls/i686/cmov/
  • #17 ??
    from /lib/tls/i686/cmov/
  • #18 g_thread_self
    from /usr/lib/
  • #19 g_main_context_iteration
    from /usr/lib/
  • #20 link_main_iteration
    at linc.c line 288
  • #21 giop_recv_buffer_get
    at giop-recv-buffer.c line 738
  • #22 ORBit_small_invoke_stub
    at orbit-small.c line 658
  • #23 ORBit_small_invoke_stub_n
    at orbit-small.c line 575
  • #24 ORBit_c_stub_invoke
    at poa.c line 2643
  • #25 Bonobo_Unknown_ref
    from /usr/lib/
  • #26 bonobo_object_dup_ref
    from /usr/lib/
  • #27 impl_desktop_get_child_at_index
    at desktop.c line 200
  • #28 _ORBIT_skel_small_Accessibility_Accessible_getChildAtIndex
    at Accessibility-common.c line 120
  • #29 ORBit_POAObject_invoke
    at poa.c line 1142
  • #30 ORBit_OAObject_invoke
    at orbit-adaptor.c line 336
  • #31 ORBit_small_invoke_adaptor
    at orbit-small.c line 844
  • #32 ORBit_POAObject_handle_request
    at poa.c line 1351
  • #33 ORBit_POAObject_invoke_incoming_request
    at poa.c line 1421
  • #34 ORBit_POA_handle_request
    at poa.c line 1643
  • #35 ORBit_handle_request
    at orbit-adaptor.c line 296
  • #36 giop_connection_handle_input
    at giop-recv-buffer.c line 1308
  • #37 link_connection_io_handler
    at linc-connection.c line 1387
  • #38 link_source_dispatch
    at linc-source.c line 159
  • #39 g_main_context_dispatch
    from /usr/lib/
  • #40 ??
    from /usr/lib/
  • #41 ??
  • #42 ??

Comment 74 Mike Pedersen 2007-02-08 05:43:40 UTC
Hi Li, just a couple things that might be useful.  I notice that I get different behavior if I have a .orbitrc containing the above lines in my home directory and my root directory.  If I have one in my home directory as well applications seem not to talk after I enter my password into the gksu password dialog.  Also, I'm not sure if I told you that in order to have the GKSU password dialog read by orca you need to check the box to disable the keyboard grab in the general tab of the orca preferences.  
hope this is of some use.  
Comment 75 Li Yuan 2007-02-08 06:28:33 UTC
Yes, I found this problem too. On your system, if there is only one .orbitrc file in /root, and if you start orca first, does gksu application work for you?
Comment 76 Mike Pedersen 2007-02-08 06:32:28 UTC
No, both the update manager and the network-admin hang for me.  Note that when they hang I am running them from the gnome-control-center not from a terminal window.  
Comment 77 bill.haneman 2007-02-08 10:56:25 UTC
Henrik; you said
"IMO, the bug status should be set back to open until this can be resolved in
code (unless this is an Ubuntu-specific problem of course)."

If by "this" you mean the need for the end-user to modify .orbitrc, then I am afraid this can never be "resolved in code" unless ORBit2 maintainers and the Gnome community (as well as distros) agree to change the ORBit2 security policy.

I disagree about reopening this bug, but opening an RFE about ORBit2 security policy (against ORBit2, probably) would seem like the right thing to do here.  Or, of course, the issue could be resolved in ubuntu by shipping the modified .orbitrc in Feisty.  (If that's not acceptable to Feisty, then logically a change in behavior making it unnecessary would also not be acceptable... ;-) )


Comment 78 Michael Meeks 2007-02-08 11:24:50 UTC
So - we should move the bug to ORBit2.

Basically IMHO it should be acceptable for an end-user's ORB to accept connections from the root user.

Indeed, it's rather a mystery as to why this is not (already) the case. Opening an IPv4 port is a disasterous solution to this problem.

What is necessary is -only- for someone to follow the straces carefully and work out why a root user is not allowed to connect; isolate that piece of code (or UDS permissions issue).

It's entirely -possible- that a simple 'chown $USER:root /tmp/orbit-$USER' and some more suitable permissions on that directory would solve the problem without any recorse to these insecure & unhelpful solutions :-)

Again - someone needs to buy a copy of Stephens Unix Network Programming, learn to use strace, get a suitable environment setup, trace the thing that fails & which should work, read the ORBit2 code, and fix it :-) this is not beyond the wit of man, but I cannot do it.
Comment 79 Henrik Nilsen Omma 2007-02-08 12:12:16 UTC
"Or, of course, the issue could be resolved in ubuntu by shipping the modified
.orbitrc in Feisty.  (If that's not acceptable to Feisty, then logically a
change in behavior making it unnecessary would also not be acceptable... ;-) )"

It's not actually the behaviour we object to but the method of relying on stock per-user configuration in order to provide what should be default behaviour. That's not maintainable in the long run and if someone wipes or alters their dot files the functionality would disappear. Bad.

If we are going to have a work-around in the short term we would rather make it opt-in and document it.
Comment 80 bill.haneman 2007-02-08 14:10:41 UTC
Michael: good point, there's no logical reason why root should not be able to connect to a user's /tmp/orbit files.  As you say, this would avoid the need to open the IPv4 port globally. ( However, as Michael notes in comment #65, we need only accept such connections from $localhost, thus the 'hole' is not particularly huge.  )

Henrik, I think rather than requiring "stock per-user" configuration, the problem should currently be solved by modifying the 'global' orbitrc (I think this is in /etc/orbitrc).  However as Michael points out, this really ought to be fixed in ORBit2 eventually, and such a fix would have fewer security implications.  

I have just opened bug #405737 regarding the ORBit2 issue (allow root to talk to user-owned ORBs w/o IP).
Comment 81 Li Yuan 2007-02-13 07:43:45 UTC
Hi everyone, I found AT will hang if I start some applications from gksu. And I got an error: 
(gedit:30392): GnomeUI-WARNING **: While connecting to session manager:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.

Does anyone have idea about this?
Comment 82 Li Yuan 2007-02-13 07:45:36 UTC
BTW: I have add the two lines in .orbitrc, and everything works fine if I just start application from root. It just doesn't work with gksu.
Comment 83 Willie Walker 2007-02-13 11:55:34 UTC
(In reply to comment #82)
> BTW: I have add the two lines in .orbitrc, and everything works fine if I just
> start application from root. It just doesn't work with gksu.

gksu does a keyboard grab, which can cause problems.  Does the stuff from comment #51 ( help?

Comment 84 Li Yuan 2007-02-14 07:22:08 UTC
(In reply to comment #83)
> (In reply to comment #82)
> > BTW: I have add the two lines in .orbitrc, and everything works fine if I just
> > start application from root. It just doesn't work with gksu.
> gksu does a keyboard grab, which can cause problems.  Does the stuff from
> comment #51 ( help?

I have set it to ture. But still hangs. The trace is But everything is OK on solaris.