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

http://mail.gnome.org/archives/gnome-accessibility-list/2005-December/msg00041.html

http://mail.gnome.org/archives/gnome-accessibility-list/2006-April/msg00055.html

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

*** Bug 164942 has been marked as a duplicate of this bug. ***

*** Bug 164941 has been marked as a duplicate of this bug. ***

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/main.c
-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:
ORBIIOPIPv4=1
ORBIIOPUNIX=0"

Created attachment 67717 [details]
Original patches for at-spir IOR work.

Original patches for at-spir IOR work.

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

*** Bug 154487 has been marked as a duplicate of this bug. ***

ariel, can we get status on this bug?  Also I don't see any dependency bug for the gdm case yet.  Thanks!

I created Bug 345434 for gdm and make it depend on Bug 163132. Maybe I should have done it the other way around. 

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.

ariel

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

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.

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.

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.

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.

Please delete my patch from comment 19, because it belongs to the gnome-session dependency of this defect.

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,

Will

Marked patch from comment 19 as obsolete (according to comment 20), as it's attached to bug 345428 already.

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 http://bugzilla.gnome.org/show_bug.cgi?id=345434) 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.

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.

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.

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

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

Created attachment 73972 [details] [review]
Remove launching of registry if user is gdm

Remove launching of registry if user is gdm.

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 on attachment 73972 [details] [review]
Remove launching of registry if user is gdm


>Index: configure.in
>===================================================================
>RCS file: /cvs/gnome/at-spi/configure.in,v
>retrieving revision 1.190
>diff -u -r1.190 configure.in
>--- configure.in	22 Aug 2006 15:06:41 -0000	1.190
>+++ configure.in	3 Oct 2006 20:54:21 -0000
>@@ -110,7 +110,8 @@
> PKG_CHECK_MODULES(ATK_BRIDGE, [
> 	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>

Remove...
...
>@@ -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 
Atom AT_SPI_IOR;
...
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,
etc.
     
...

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



Bill

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

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.

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.

I'll test i today and write the Changelog

ariel

"I will roll
into the tarball for gnome 2.17.1." ==> (If/when the gnome-session patch is accepted)

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.

Created attachment 74838 [details] [review]
Add Changelog

Changelog added.
Tested your patch and works nice.

Fixed in CVS; thanks all!

Hello,

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?

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.

ariel

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. 

It looks like you need to:

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

ORBIIOPIPv4=1
ORBIIOPUNIX=0 
(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

ariel

OK,

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.

Al, are you able to accessibly dectect menu launched applications using at-poke?

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?

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.

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.

Should this be globally set in /etc/orbitrc?

If you set it globally it won't work. YOu need to have 
ORBIIOPIPv4=1
ORBIIOPUNIX=0 
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.

ariel

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?

regards

Bill

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"

Willie,

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.

ariel

Please check bug 377079, which is related to this commit.

> 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 "./autogen.sh --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 http://bugzilla.gnome.org/show_bug.cgi?id=163132#c43, 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.

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 http://archive.ubuntu.com/ubuntu/ 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.

Ok I am going to install ubuntu and try Daniel's instructions so we can have a similar environment to test.

ariel

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.

Thanks Ariel - I uploaded the patch to Ubuntu Feisty today, let's see if it fixes the problem for everybody.

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: 
ORBIIOPIPv4=1
ORBIIOPUNIX=0"
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

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

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?

http://www.linuxfromscratch.org/blfs/view/stable/gnome/java-access-bridge.html

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.

Should these environment variables be glocally set in /etc/profile.d/a11y.sh for atk-bridge and the java-access-bridge?

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.

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 OpenOffice.org to use a native bridge ].

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.

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.

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.

Is there any chance that this patch would interfere with gnome-panel applet events?  Please see bug #400709.  Thanks!!

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?

Hi Bill.  Thanks for the quick response!  The system in question has libgail-gnome.  Other thoughts/ideas?

I can confirm that simply setting:
ORBIIOPIPv4=1
ORBIIOPUNIX=0

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

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:

+ Trace 108939

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.  

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?

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.  

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

regards,

Bill

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.

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

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

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?

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.

(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 (http://bugzilla.gnome.org/show_bug.cgi?id=163132#c51) help?

(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 (http://bugzilla.gnome.org/show_bug.cgi?id=163132#c51) help?
> 

I have set it to ture. But still hangs. The trace is http://bugzilla.gnome.org/show_bug.cgi?id=163132#c73. But everything is OK on solaris.