[Webkit-unassigned] [Bug 219010] New: [WPE][GTK] SleepDisabler does not inhibit sleep with bubblewrap sandbox enabled

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=219010

            Bug ID: 219010
           Summary: [WPE][GTK] SleepDisabler does not inhibit sleep with
                    bubblewrap sandbox enabled
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at gnome.org
                CC: bugs-noreply at webkitgtk.org, pgriffis at igalia.com
            Blocks: 206533

Splitting this out of bug #186971. Sleep inhibitors are broken since the bubblewrap sandbox is enabled. First problem is that the org.freedesktop.ScreenSaver API is not allowed through the sandbox, so calls to that fail. (We could fix this bug by whitelisting it. That's the easy way.) It falls back to the portal API. (Ideally, we would call the modern portal API first, and fall back to the older ScreenSaver API only if portals are not supported.) Now, the portal API fails for a strange reason. For the portal API, we aren't trusted to provide our own app ID, so xdg-desktop-portal looks it up by (a) getting our pid from its D-Bus connection, via UNIX credentials to ensure it is trusted, then (b) opening /proc/$PID/root/.flatpak-info to read the app ID from there, which the app cannot falsify because it does not have write access. BubblewrapLauncher.cpp creates this file by passing a sealed memfd to bwrap's --ro-bind-data. To be completely certain it is property created inside the sandbox, I added some debug code to SleepDisablerGLib.cpp:

 void SleepDisablerGLib::acquireInhibitorViaInhibitPortalProxy()
 {
+WTFLogAlways("%s", __FUNCTION__);
+GUniqueOutPtr<char> contents;
+GUniqueOutPtr<GError> error;
+g_file_get_contents("/.flatpak-info", &contents.outPtr(), nullptr, &error.outPtr());
+if (!error)
+g_warning("contents=%s", contents.get());
+else g_warning("error=%s", error->message);

which prints:

contents=[Application]
name=org.gnome.Epiphany

So that seems to be working properly. Problem is, for some reason, it doesn't exist at /proc/$PID/root/.flatpak-info on the host, so xdg-destkop-portal cannot see it! For real flatpaks, the file exists here (and contains a lot more than just the app ID). I'm bamboozled as to why the file is visible inside the sandbox, but is not there in the host's view of the sandbox.


Referenced Bugs:

https://bugs.webkit.org/show_bug.cgi?id=206533
[Bug 206533] [WPE][GTK] Tracker for sandbox issues
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201117/75f69bd5/attachment.htm>