Screen sharing configuration on wayland #3872
Comments
|
If anyone wonders about how this screen capture works, it has been added to firefox 84 and requires pipewire. More information here: https://wiki.archlinux.org/index.php/Screen_capture#Via_the_WebRTC_protocol |
Just that line? In my tests also
|
|
Sorry for the late answer.
But does this mean that an untrusted app could get the screen content without the user being aware of it? Cheers! |
|
Crazy, the first time I allow sharing it aborts immediately and the second allow always works. I can confirm that it works with
I was talking about
Portals originate from flatpak and were developed with the intention to be exposed to a sandbox. Every flatpak can talk to Brief summary of their function: sandboxed program talks to |
|
Thanks for your explanation!
In my case (Sway and xdg-desktop-portal-wlr), do you mean that xdg-desktop-portal-wlr should send a notification when the screen is shared? (notification sent over DBUS to a notification daemon (like mako in my case)? |
|
Ok, if xdg-desktop-portal-wlr does this w/o user interaction that's bad. Under GNOME (xdg-desktop-portal-gtk is the most developed portal implementation) I get a dialog what I want to share. Firefox has nothing to share until I click "Freigeben" (=share). Dialog
In addition there is a orange indicator (everything else is white).
I could found any spec saying a desktop-portal MUST ask/notifiy. However the idea of portal is that the user has the control (i.e. he/she is asked to allow a program access to something) and it is transparent to the user what happening (i.e. notifications or indicators). If the desktop-portal just allows everything, there is no advantage in using portal over direct access. |
|
Thank your very much for your screenshots, now I understand :-)
|
|
Just wanted to point out that if you try to run firefox so that it actually uses wayland (env GDK_BACKEND=wayland firefox), this solution appears to be broken. I added the dbus-user.talk org.freedesktop.portal.* line and it launches, but does not resolve the issue. As soon as I added whitelist ${RUNUSER}/pipewire-0 line, firejail + firefox won't launch. If I instead add include whitelist-runuser-common.inc then it launches, but again, does not work. I'm running firefox 85, wayland + KDE 5.20.5 on Debian Testing with the newest (working) pipewire version. I have tested firefox without using firejail and it does, indeed, work correctly. I've also tested obs studio screen recording on wayland and it work perfectly fine as well. So the issue remains that firejail is blocking something when firefox is told to use wayland as opposed to xwayland. The proposed solutions here do seem to work on the default xwayland setup but for those of us who want a nice browsing experience on a touch screen laptop that isn't completely janky and broken, a real wayland backend is very much the only way to go. Hopefully there's a viable work around for this. |
@Luticus Unrelated note: I always assumed that it's safer to use the officially supported MOZ_xxx env vars with Firefox, independent of DE. So to force FF to use Wayland that would be MOZ_ENABLE_WAYLAND=1. |
|
@glitsj16 I'll give that a try. I've been using the GDK_BACKEND one for a while because when I researched it that's what I found and it seemed to work. I'll test with the one you suggest and see if it works/improves anything in any way. |
|
@glitsj16 So after testing the difference between using the two wayland methods, it seems MOZ_ENABLE_WAYLAND=1 simply "less forceful". What I mean is that when wayland fails for some reason Firefox will fall back on xwayland, whereas the GDK_BACKEND method will prevent Firefox from starting if it fails. At least that's how it seemed. When I used whitelist ${RUNUSER}/pipewire-0 with the MOZ_ENABLE_WAYLAND=1 method, Firefox did start but when I went to about:support "window protocol" it was using xwayland, and without the whitelist line, it used wayland. With the GDK_BACKEND method Firefox would not launch while whitelist ${RUNUSER}/pipewire-0 was in the ~/.config/firejail/firefox.local file. Without the whitelist line, Firefox works fine with wayland but doesn't work with pipewire. |
|
@Luticus: On ArchLinux, it is working fine but I am running firejail version 0.9.64-2 et its /etc/firejail/* profiles are probably different than yours. Indeed, in my setup (profiles older than the ones on master), my /etc/firejail/firefox-common.profile file does not |
It maybe also changes some code paths which are unrelated to the rendering-backend-frontend like screensharing, because GDK_BACKEND is (maybe) (only) for gdk.
I guess it's the KDE. That a third protal implementation (I've GNOME and @albinou has sway). (or the firefox 85 is the cause, I will test once fedora ships it in the next days.)
If you add
That's it, w/o wruc you has full* access to ${RUNUSER} *the blacklist from disable-common.inc is still used
Just use |
|
Well I tried running my ~/.config/firejail/firefox.local in several different variations and none worked. Here's a list of some of the lines I tried: I wasn't sure if gtk apps would use the gtk backend so i installed it and enabled it just in case. The dbus lines were taken from the qdbus | grep portal command. I also tried with the dbus-user.talk org.freedesktop.portal.* setting, but with no success. One thing I did notice is that once I added the include whitelist-runuser-common.inc with whitelist ${RUNUSER}/pipewire-0 the browser would launch with the wayland backend, but the screen share select window does not pop up. Again, if I run my Firefox with all the same setting, and exclude only firejail, then screen sharing works perfectly. So I know I don't need a different backend, or anything like that. |
|
The issue is the noroot directive in firefox-common. If that is commented out, it works. Even if I completely remove the firefox.local file and make no other changes. I just had to stop using that noroot directive. Not sure if there's a work around where I can still use that and be able to use screen sharing, but for now I'll just leave it commented until there's a better workaround. |
|
FTR: The portal implementations at |
|
@Luticus: My ArchLinux updated its firejail version and, FYI, I don't need to whitelist ${RUNUSER}/wayland-0 |
|
@ anyone how is this confused about whitelisting: If you use firejail <= 0.9.62 your firefox-common.profile has no wruc so you don't need If you use firejail >= 0.9.64 your firefox-common.profile has wruc and only file with a |
|
Summary: Wayland screen-sharing requires So @albinou feel free to open a PR with something like |
|
I can't get to link my pull request :-/ |
|
The pull request has been merged. We can close this issue. |
|
To get xdg-desktop-portal-wlr working with Sway on Arch Linux I needed the following lines for these various browsers: FirefoxGoogle ChromeChromium |
Interesting. Maybe that's why screen-sharing it did not worked for me when I last tried/needed.
Already in whitelist-runuser-common.inc
and |
|
Very nice, thanks @alxjsn ! I only needed to add the following line to my firefox and chromium config:
@alxjsn: Do you want to propose a PR to add this (as comment) in config files? Or I can do it if you want. |
|
@albinou @rusty-snake created a PR here: #4368 |
Address #3872 with changes in pipewire for Firefox and Chromium
|
To get xdg-desktop-portal-gtk working with Gnome on Gentoo Linux I needed the following lines for these various applications: Firefox~/.config/firejail/firefox-common.local: Google Chrome(working w/o any additional firejail local configs) Telegram Desktop~/.config/firejail/telegram.local: ~/.config/firejail/whitelist-runuser-common.local: My current config:gnome-base/gnome-shell-41.1 |
Bug and expected behavior
Solution
This can be fixed by allowing the required DBUS message. This can be done by creating a
~/.config/firejail/firefox.localfile with the following content:There's no bug then?
No indeed, because I am not sure this DBUS message should be allowed by default.
I am just wondering if/where this should be documented because it is not specific to firefox.
Indeed, the same configuration could be required for other applications (like chromium, zoom, teams, ...).
Don't hesitate to ask me to propose a PR, I would be happy to help.
The text was updated successfully, but these errors were encountered: