I'm working on an issue  in GNU Guix's WebKitGTK package. In the issue,
I've identified what I believe to be a problem at the intersection of
Bubblewrap, WebKitGTK, and Guix. I believe that the source of the problem
is that with Guix, files that are needed in the sandbox are located in
unexpected places. Everything manages by Guix, such as packages and
configuration files, gets its own path under /gnu/store (answering why it
is this way is a longer discussion which I'll leave to the manual  for
now, but I find it compelling). Some files and directories under /run and
/etc are symlinks to their canonical location under /gnu/store.
I believe that this arrangement will require extra paths to be bound into
Bubblwrap's new mount namespace. However, it isn't clear to me what they
are. I have tried patching BubblewrapLauncher.cpp, but it still seems to
get tripped up with the pulse/client.conf symlink. I have not been able to
reproduce the problem with simple interactive invocations of bwrap.
I'm interested in hearing how to troubleshoot problems like:
bwrap: Can't create file at /etc/pulse/client.conf: No such file or directory
bwrap: Can't mkdir parents for /run/current-system/profile/lib/gstreamer-1.0: No such file or directory
I'm also interested in hearing how to best integrate WebKitGTK with Guix.
I suppose the ideal case is for WebKitGTK to detect situations like
Guix's and call bwrap with the correct arguments, and to fall back to
carrying a local patch in Guix if a general solution is not appropriate.
> On Mon, Apr 27, 2020 at 11:22 pm, Jack Hill <[hidden email]> wrote:
>> Can this problem be worked-around in WebKitGTK?
> Looks like WebKit should call realpath() for each path it passes to bwrap.
> Annoying, but certainly doable. Want to report a bug for it on WebKit