[Webkit-unassigned] [Bug 239682] [GTK] Bubblewrap sandbox lacks support for pipewire

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Haelwenn (lanodan) Monnier <contact+bugs.webkit.org at hacktivis.me> ---
(In reply to Michael Catanzaro from comment #1)
> Comment on attachment 458194 [details]
> Patch: BubblewrapLauncher.cpp: Add paths required for pipewire
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=458194&action=review
> 
> > Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp:308
> > +    if(!pwRemote) {
> 
> if (!pwRemote) {
> 
> > Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp:316
> > +    GUniquePtr<char> pwRuntimeFile(g_build_filename(pwRuntimeDir, pwRemote, nullptr));
> > +    bindIfExists(args, pwRuntimeFile.get(), BindFlags::ReadWrite);
> 
> Well this can't be right, because pwRuntimeDir will generally be nullptr. We
> should only attempt to bind this location if pwRuntimeDir is set. But if it
> is, then we probably want to use it *instead* of xdgRuntimeDir, right?

Right.

> > Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp:319
> > +    GUniquePtr<char> xdgRuntimeFile(g_build_filename(xdgRuntimeDir, pwRemote, nullptr));
> > +    bindIfExists(args, xdgRuntimeFile.get(), BindFlags::ReadWrite);
> > +
> > +    GUniquePtr<char> pwRuntimeFile(g_build_filename(pwRuntimeDir, pwRemote, nullptr));
> > +    bindIfExists(args, pwRuntimeFile.get(), BindFlags::ReadWrite);
> > +
> > +    GUniquePtr<char> sysRuntimeFile(g_build_filename("/run/pipewire", pwRemote, nullptr));
> > +    bindIfExists(args, sysRuntimeFile.get(), BindFlags::ReadWrite);
> 
> And /run/pipewire doesn't exist at all on my system. When does pipewire
> actually use this? There is always a valid XDG runtime dir even if the
> environment variable is unset, so I'm not sure why pipewire would ever fall
> back to this location.

/run/pipewire is for when pipewire is started by the system to be used by everyone instead of being bound to your user.
Pipewire clients try to connect to it when it failed to connect to the runtime-dir based one.

> Anyway, I think what you're trying to do is "bind the pipewire socket,
> wherever it exists," right? Probably we can implement the same lookup
> strategy used by pipewire itself? I notice that we can't copy from flatpak,
> because flatpak doesn't actually grant access to the pipewire socket. I
> suppose flatpak expects apps to go through the pulseaudio socket instead?

I haven't looked on the flatpak side of things, I'm not really familiar with it.

Within pipewire itself, the relevant code seems to be at
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/modules/module-protocol-native/local-socket.c
and it is setting up a namespace rather than a proxy so using the exact same strategy probably wouldn't work.

-- 
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/20220423/6d0c3f87/attachment.htm>