Make accessibility work in the sandbox #79
Comments
|
We talked a bit about this at the GTK+ hackfest. I believe the current plan is to a) patch at-spi-atk to look for the a11y bus socked in XDG_RUNTIME_DIR, b) expose the socked the same way we do for the session bus and c) give apps limited access to the bus that is sufficient to make orca work |
|
It turns out however that apps need to be able to send messages to some services on the a11y bus, which is complicated due to security reasons. |
|
many developers do not care about accessibility, so it would be useful to grant such access by default, as there is a chance most of them just will ignore that |
|
The problem isn't simply about granting access, but about the technical problems of having a 2nd, separate, D-Bus daemon running, and the fact that all sandboxed applications would share it. |
|
It is extremely important that BOTH Orca AND brltty will be made to work with flatpak. I am blind and it is important for me that Orca screen reader, speech synthesizers and brltty do work in the future too. brltty is important too because it is needed if you want to use braille display. Orca uses brltty. |
This creates a dbus proxy for the a11y bus and sets AT_SPI_BUS_ADDRESS in the environment to the filtered bus. The app is only allowed to talk to org.a11y.atspi.Registry on the bus. This requires a patch to at-spi2-core to read the address from AT_SPI_BUS_ADDRESS: https://github.com/flatpak/freedesktop-sdk-images/blob/1.6/at-spi2-core-address-env-var.patch This is work-in-progress, see discussion in flatpak#79
|
Ok, I started looking into this. Here is how a11y works from high level perspective: There is a a11y bus, which is separate from the session bus, but you can get the address to it from the session bus, or from a X11 root-window property. Each a11y client connects to this bus, as does the at-spi registry daemon. Normally, an a11y client talks directly only to to the registry daemon, and additionally it broadcasts signals when its properties change. Additionally it exposes on the bus a lot of objects that anyone can call, which do things like expose all the widgets and let you see and modify their state. As a special case, for socket/plug embedding it seems like the a11y client might call directly to the parent/child. A11y services, like orca, connect to the same bus, and then asks the registry about what is happening, and then calls directly into the clients to read and modify them. I created a brach with some start of a11 support here: https://github.com/alexlarsson/flatpak/tree/wip/a11y It works by creating a dbus proxy for the a11y bus, and exporting the address via the AT_SPI_BUS_ADDRESS env var (requires a patch to at-spi2-core to pick up the env var). On this bus the app is only allowed to talk to the registry, send broadcast signals and reply to messages sent directly to it. It can't directly talk to others, or receive signals broadcast from them.This seems to be enough to make at least orca work. However, there are at least a few issues that prevent this from being truly safe:
I can think of two ways to make this safe. Either modify the registry itself to only allow certain operations if the client is sandboxed. Alternatively, we could make the dbus proxy filter more complicated (although this risks slowing it down, and could cause issues when we later try to move the dbus filtering from the proxy into dbus itself). @mgorse, @joanmarie could you help us figure out what subset of the registry would be "safe" for a sandboxed client to use? @smcv what are the possible extensions of the new dbus container rules we could make that would let us filter things with a higher degree of accuracy? For instance, could we add filters on interface name? method name? object path? |
This needs fixing anyway. The easiest way would be for AT-SPI to detect whether Alternatively, dbus 1.11.x has a new listenable address family |
https://bugs.freedesktop.org/show_bug.cgi?id=100344 is the metabug with the general design, and https://bugs.freedesktop.org/show_bug.cgi?id=101902 is the feature request for filtering. Interface name is fine, we probably want that anyway. Object path is fine, desrt wants that anyway for dconf. Object path subtrees (ask for I would prefer not to support filtering by member (method, signal) name if we can help it, because interfaces and object paths seem a much more reasonable granularity to work at. |
a11y people: Please clarify the multiplicity of this bus? If uid 1000 logs in on seat0 with X11 display :1 and on seat1 with X11 display :2, how many a11y buses do they have? (I believe the answer is: two, one per X11 display) If uid 1001 on X11 display :3 uses pkexec or sux or something to run a GUI application on :3 as uid 0 (I know this is inadvisable and deprecated, but it happens), how many a11y buses are there? (I believe the answer is: there is one a11y bus, and both uid 1001 and uid 0 are connected to it) |
|
@smcv You find the a11y normally via either a X11 root property, or via a service on the session bus. So, there is one per display if you're using X11, and one per dbus session if you're using wayland i guess... |
|
@smcv So, there are a unfortunately a bunch of methods we'd like to call intermixed with ones that are dangerous. For instance, we need to call org.a11y.atspi.DeviceEventController.GetKeystrokeListeners() to know if there is anyone listening for these, and if so, we should send them. But we don't want the sandboxed apps to call e.g. org.a11y.atspi.DeviceEventController.GenerateKeyboardEvent. In the proxy i'm probably going to be filtering this by method. But, long term i think a better approach is to filter by interface only, and splitting out the safe methods into a separate interface. Another problem is that atk calls the above methods, which give us list of unique names on the bus. And atk then listens for NameOwnerChanges on these so that we can track the lifetime of them. This is so we can stop sending signals when there is nobody listening to some specific type of event anymore. But, we currently filter out all the NameOwnerChanges you can't see, which makes this not work. |
|
New version has support in the dbus-proxy for per-iface+method+path filtering, and a very limited set of allowed calls: Additionally it runs the a11y bus in a "sloppy names" mode where all clients are allowed to see NameOwnerChanged events for all unique names, so that they can track lifetimes of a11y services. I believe these are safe, and enough. A trivial test of orca against gtk3-demo seems to work. But, it would be nice to have some review from people involved in a11y. |
I suppose in dbus we could have a flag INTERFACE_IS_REALLY_MEMBER and set the "interface" in the data structure to be inter.face.member instead of inter.face. Then we wouldn't need a separate field for the member name. It's a bit ugly, but if we need it, we need it.
This seems like a viable flag to add. |
|
Hi
I am not developer, I am just a blind user. So I have no idea if this
has anything to do with you are talking about. I just want to note that
many braille displays do have an integrated braille keyboard. Both the
braille display and the integrated braille keyboard in the braille
display are controlled by brltty. Braille keyboard is not like normal PC
keyboard. Braille keyboards are typically integrated into braille
display, but there are also some separate braille keyboards. Braille
display typically has8 dot -keys which are used to write all the
letters, numbers etc. Braille keyboard also has a space bar and number
of control buttons and switches.
As a blind user it is extremely important that all of this works and
user is able to:
1) Use Orca screen reader which speaks the content on screen
2) read the text on screen using braille display. It is important to be
able to read both text in documents and text in application user interface.
3) write text using the integrated braille keyboard
4) use braille display and braille keyboard both on desktop and console.
Orca uses brltty.
I do not know how brltty exactly works, but it does translate braille
keyboard presses into normal letters, numbers etc using key tables. So
maybe it does generate keyboard events so that text can be entered.
But as I said I really do not know how those really work.
…On 09/01/2017 01:45 PM, Alexander Larsson wrote:
@smcv <https://github.com/smcv> So, there are a unfortunately a bunch
of methods we'd like to call intermixed with ones that are dangerous.
For instance, we need to call
org.a11y.atspi.DeviceEventController.GetKeystrokeListeners() to know
if there is anyone listening for these, and if so, we should send
them. But we don't want the sandboxed apps to call e.g.
org.a11y.atspi.DeviceEventController.GenerateKeyboardEvent.
In the proxy i'm probably going to be filtering this by method. But,
long term i think a better approach is to filter by interface only,
and splitting out the safe methods into a separate interface.
Another problem is that atk calls the above methods, which give us
list of unique names on the bus. And atk then listens for
NameOwnerChanges on these so that we can track the lifetime of them.
This is so we can stop sending signals when there is nobody listening
to some specific type of event anymore.
But, we currently filter out all the NameOwnerChanges you can't see,
which makes this not work.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AcTIrsIjBWD1QPRv4hm7dfKGHGCo6oGvks5sd-BGgaJpZM4ItZjK>.
|
This will be used for flatpak to set a custom bus (which is really the bus proxy). It can be used for testing purposes too. For more details, see flatpak/flatpak#79 https://bugzilla.gnome.org/show_bug.cgi?id=787126
Orca, and brltty should both work as they run outside the sandbox, in the "OS" part of the system. If brltty works in Wayland, then there's no reason for it not to work once the application is sandboxed. |
Accessibility works by having its own dbus bus, which currently doesn't work at all in the sandbox. However, just granting access to it is extremely unsafe as it can basically control anything. This needs serious research into how its going to work.
The text was updated successfully, but these errors were encountered: