[Pipewire] screen sharing does not use the portal provided file descriptor
Categories
(Core :: WebRTC, defect)
Tracking
()
People
(Reporter: rmader, Assigned: rmader)
References
(Blocks 2 open bugs)
Details
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
When requesting a Pipewire screen casting stream via the portal[1] we do get a specific pipewire FD that only contains the selected screen casts. While we do receive that FD[2], we never use is later on[3]. Apparently we rely on having full access to Pipewire and not being sandboxed. This is relevant if we want to tighten up the permissions for the Flatpak build.
From the spec:
OpenPipeWireRemote:
@session_handle: Object path for the #org.freedesktop.portal.Session object
@options: Vardict with optional further information
@fd: File descriptor of an open PipeWire remote.
Open a file descriptor to the PipeWire remote where the screen cast
streams are available. The file descriptor should be used to create a
<classname>pw_remote</classname> object, by using
<function>pw_remote_connect_fd</function>. Only the screen cast stream
nodes will be available from this PipeWire node.
1: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.ScreenCast.xml
2: https://searchfox.org/mozilla-central/source/third_party/libwebrtc/webrtc/modules/desktop_capture/linux/base_capturer_pipewire.cc#852
3: https://searchfox.org/mozilla-central/search?q=pw_fd_&path=&case=false®exp=false
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
It is needed for restricted pipewire access. The FD is provided
by xdg-desktop-portals such as the one for screen casting.
Not using the portal provided FD means we need full Pipewire
access, even in a Flatpak sandbox.
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
We already requested the FD from the portal but then just opened a
normal connection. The screen cast portal explicitly states that
the FD returned by OpenPipeWireRemote()
should be used with
pw_remote_connect_fd()
- the later is Pipewire 0.2 API that got
replaced by pw_context_connect_fd()
.
Depends on D122903
Assignee | ||
Updated•3 years ago
|
Pushed by robert.mader@posteo.de: https://hg.mozilla.org/integration/autoland/rev/954af8b51c87 Add pw_context_connect_fd() to mozpipewire, r=stransky https://hg.mozilla.org/integration/autoland/rev/90493ccbbb35 Use portal provided file descriptor for screen casting, r=stransky
Comment 4•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/954af8b51c87
https://hg.mozilla.org/mozilla-central/rev/90493ccbbb35
Comment 5•3 years ago
|
||
Can those two revisions please be uplifted to 91esr ?
They are needed to make screen capture work in the firefox snap that is built from the ESR branch. Thanks!
Assignee | ||
Comment 6•3 years ago
|
||
Comment on attachment 9236725 [details]
Bug 1726211 - Use portal provided file descriptor for screen casting, r=stransky
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: Quoting bug 1726211 comment 5:
They are needed to make screen capture work in the firefox snap that is built from the ESR branch.
- User impact if declined: See above
- Fix Landed on Version: 93
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The code change is very simple and has also been uplifted to upstream WebRTC. I.e. is not only used in Firefox stable but also all Chromium products.
- String or UUID changes made by this patch:
Assignee | ||
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Thanks Robert!
Updated•3 years ago
|
Comment 8•3 years ago
|
||
Comment on attachment 9236724 [details]
Bug 1726211 - Add pw_context_connect_fd() to mozpipewire, r=stransky
Approved for 91.3esr.
Updated•3 years ago
|
Comment 9•3 years ago
|
||
bugherder uplift |
Description
•