-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't require TALK permission for broadcast rules #61
Don't require TALK permission for broadcast rules #61
Conversation
The context is to allow for AT-SPI broadcast signals (specifically `EventListenerRegistered` and `EventListenerDeregistered` from the `org.a11y.atspi.Registry` interface on the registry object) to be allowed through, without giving apps a full talk permission to it.
I do wonder if the simplest solution would be for flatpak to always set up the a11y bus proxy with:
After all, there's already a:
in the proxy set up function. Would that work too? |
Basically |
I'm going to try and be a bit more helpful and expand on my previous comment. According to this comment in the D-Bus bugtracker:
This is implemented by xdg-dbus-proxy in the following lines: xdg-dbus-proxy/flatpak-proxy.c Lines 2746 to 2752 in 1bcfaea
As a consequence, in order to pass What I'm proposing here in this PR is, specifically, to allow |
Right that makes sense.
What kind of objects? Can we limit that to the |
I was thinking of
Not with today's xdg-dbus-proxy. Right now, |
Thanks to Philip's review, and after a better read at https://gitlab.freedesktop.org/dbus/dbus/-/issues/185, I actually think this PR implements the exact proposed behaviour described in that issue. Comment dbus/dbus#185#note_48129 reads:
and comment dbus/dbus#185#note_48130 reads:
So to the best of my understanding, in practice these two comments propose that:
Which is exactly what this PR implements. |
These signals can be used by apps to monitor whether they need to emit signals on the a11y bus or not. This can very significantly reduce chattery on the a11y bus, and at least WebKit relies on these signals to be broadcasted in. The PR flatpak/xdg-dbus-proxy#61 is required for this changeset to work as expected, but it can land independently as `--broadcast` is supported by xdg-dbus-proxy.
OK LGTM! Sorry for the delay in taking another look at this |
These signals can be used by apps to monitor whether they need to emit signals on the a11y bus or not. This can very significantly reduce chattery on the a11y bus, and at least WebKit relies on these signals to be broadcasted in. The PR flatpak/xdg-dbus-proxy#61 is required for this changeset to work as expected, but it can land independently as `--broadcast` is supported by xdg-dbus-proxy.
These signals can be used by apps to monitor whether they need to emit signals on the a11y bus or not. This can very significantly reduce chattery on the a11y bus, and at least WebKit relies on these signals to be broadcasted in. The PR flatpak/xdg-dbus-proxy#61 is required for this changeset to work as expected, but it can land independently as `--broadcast` is supported by xdg-dbus-proxy.
The context is to allow for AT-SPI broadcast signals (specifically
EventListenerRegistered
andEventListenerDeregistered
from theorg.a11y.atspi.Registry
interface on the registry object) to be allowed through, without giving apps a full talk permission to it.CC @ebassi @smcv
@smcv I appreciate this goes directly against https://gitlab.freedesktop.org/dbus/dbus/-/issues/185#note_48128, but I don't understand that restriction and would appreciate some ellucidation as to why that's been proposed. I'm not particularly sold on this approach so any advice will be highly welcomed!Edit: see #61 (comment) for a more up-to-date understanding of the D-Bus issue.