flatpak-spawn: Add "--sandbox-a11y-own-name" #67
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the flatpak-spawn counterpart to the new option of the Flatpak portal. See flatpak/flatpak#5898
TingPing
reviewed
Aug 14, 2024
TingPing
approved these changes
Aug 14, 2024
GeorgesStavracas
added a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Aug 15, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by NOBODY (OOPS!). Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess0, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess):
GeorgesStavracas
added a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Aug 15, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by NOBODY (OOPS!). Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess0, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess):
GeorgesStavracas
added a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Aug 19, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by NOBODY (OOPS!). Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess0, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. The Bubblewrap code path merely lets the single xdg-dbus-proxy instance own {appid}.Sandboxed.* which is not ideal. However, changing that would require changing the sandbox process layout, which is a tad too much for a single commit. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess):
GeorgesStavracas
added a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Oct 1, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by NOBODY (OOPS!). Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess-UUID, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. The Bubblewrap code path merely lets the single xdg-dbus-proxy instance own {appid}.Sandboxed.* which is not ideal. However, changing that would require changing the sandbox process layout, which is a tad too much for a single commit. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess):
GeorgesStavracas
added a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Oct 7, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by NOBODY (OOPS!). Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess-UUID, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. The Bubblewrap code path does the same, it lets the Web process own the specific a11y bus name assigned from the UI process. To do that, change XDGDBusProxy to spawn once for each Web process, instead of once for all Web processes. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess):
GeorgesStavracas
added a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Oct 8, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by NOBODY (OOPS!). Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess-UUID, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. The Bubblewrap code path does the same, it lets the Web process own the specific a11y bus name assigned from the UI process. To do that, change XDGDBusProxy to spawn once for each Web process, instead of once for all Web processes. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess):
GeorgesStavracas
added a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Oct 9, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by NOBODY (OOPS!). Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess-UUID, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. The Bubblewrap code path does the same, it lets the Web process own the specific a11y bus name assigned from the UI process. To do that, change XDGDBusProxy to spawn once for each Web process, instead of once for all Web processes. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess):
GeorgesStavracas
added a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Oct 9, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by NOBODY (OOPS!). Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess-UUID, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. The Bubblewrap code path does the same, it lets the Web process own the specific a11y bus name assigned from the UI process. To do that, change XDGDBusProxy to spawn once for each Web process, instead of once for all Web processes. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess):
webkit-commit-queue
pushed a commit
to GeorgesStavracas/WebKit
that referenced
this pull request
Oct 9, 2024
https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by Michael Catanzaro. Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess-UUID, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. The Bubblewrap code path does the same, it lets the Web process own the specific a11y bus name assigned from the UI process. To do that, change XDGDBusProxy to spawn once for each Web process, instead of once for all Web processes. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess): Canonical link: https://commits.webkit.org/284894@main
aperezdc
pushed a commit
to WebKit/WebKit
that referenced
this pull request
Oct 9, 2024
…gi?id=273245 [GTK][WPE] Own well-known bus name on a11y bus https://bugs.webkit.org/show_bug.cgi?id=273245 Reviewed by Michael Catanzaro. Currently WebKit on Linux is not accesible when running under Flatpak, because the Web process and the UI process cannot communicate across sandbox boundaries and connect their a11y trees. Fundamentally, the problem is that Flatpak creates a separate sandbox for the Web process, but doesn't let the UI process sandbox talk to it. It cannot, after all - Flatpak cannot know ahead of time which D-Bus name the Web process sandboxes will end up having! One way to circumvent this in a well tested manner, is to use well-known names to identify the Web process in the a11y bus. The idea is that the UI process will talk to a bus name that Flatpak can verify at runtime, e.g. org.gnome.Epiphany.Sandboxed.WebProcess-UUID, instead of an opaque unique name (e.g. :1.321). This is possible on Flatpak as per portal version 7, which introduces the necessary plumbing for the a11y bus ownership to pass through. The Bubblewrap code path does the same, it lets the Web process own the specific a11y bus name assigned from the UI process. To do that, change XDGDBusProxy to spawn once for each Web process, instead of once for all Web processes. See flatpak/flatpak#5898 See flatpak/flatpak-xdg-utils#67 * Source/WTF/wtf/glib/Sandbox.cpp: (WTF::checkFlatpakPortalVersion): (WTF::sandboxedAccessibilityBusName): (WTF::setSandboxedAccessibilityBusName): * Source/WTF/wtf/glib/Sandbox.h: * Source/WebCore/accessibility/atspi/AccessibilityAtspi.cpp: (WebCore::AccessibilityAtspi::connect): (WebCore::AccessibilityAtspi::didConnect): (WebCore::AccessibilityAtspi::didOwnName): (WebCore::AccessibilityAtspi::registerRoot): * Source/WebCore/accessibility/atspi/AccessibilityAtspi.h: * Source/WebKit/Shared/WebProcessCreationParameters.h: * Source/WebKit/Shared/WebProcessCreationParameters.serialization.in: * Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp: (webkitWebViewBaseSetPlugID): * Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp: (WebKit::flatpakSpawn): * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): * Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp: (WebKit::XDGDBusProxy::accessibilityProxy): * Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp: (WebKit::WebProcessPool::platformInitializeWebProcess): * Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp: (WebKit::WebPageProxy::bindAccessibilityTree): * Source/WebKit/WebProcess/glib/WebProcessGLib.cpp: (WebKit::WebProcess::platformInitializeWebProcess): Canonical link: https://commits.webkit.org/284894@main Canonical link: https://commits.webkit.org/282416.203@webkitglib/2.46
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the flatpak-spawn counterpart to the new option of the Flatpak portal.
See flatpak/flatpak#5898