Screen sharing configuration on wayland

[albinou]

Bug and expected behavior

• Run firefox with the firefox profile
• Open https://mozilla.github.io/webrtc-landing/gum_test.html
• Click on "Screen Capture"
• firefox asks for permission to share the screen but nothing is displayed

Solution
This can be fixed by allowing the required DBUS message. This can be done by creating a ~/.config/firejail/firefox.local file with the following content:

dbus-user.talk org.freedesktop.portal.Desktop

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.

[albinou]

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

[rusty-snake]

This can be fixed by allowing the required DBUS message. This can be done by creating a ~/.config/firejail/firefox.local file with the following content:

Just that line? In my tests also whitelist ${RUNUSER}/pipewire-0 (w/o you get the prompt, but the shared screen in empty) and ignore noroot (which is known to break portals). See #3766 (comment).

No indeed, because I am not sure this DBUS message should be allowed by default.

dbus-user.talk org.freedesktop.portal.* are considered sandbox safe and could be allowed by default.

[albinou]

Sorry for the late answer.

Just that line? In my tests also whitelist ${RUNUSER}/pipewire-0 (w/o you get the prompt, but the shared screen in empty) and ignore noroot (which is known to break portals). See #3766 (comment).

noroot is indeed set in my /etc/firejail/firefox-common.profile file (ArchLinux, firejail 0.9.64-2).
And I think ${RUNUSER}/pipewire-0 is not blacklisted because firefox-common.profile only includes disable-common.inc and the pipewire socket is not disabled.

No indeed, because I am not sure this DBUS message should be allowed by default.

dbus-user.talk org.freedesktop.portal.* are considered sandbox safe and could be allowed by default.

But does this mean that an untrusted app could get the screen content without the user being aware of it?

Cheers!

[rusty-snake]

Crazy, the first time I allow sharing it aborts immediately and the second allow always works.

I can confirm that it works with noroot.

And I think ${RUNUSER}/pipewire-0 is not blacklisted because firefox-common.profile only includes disable-common.inc and the pipewire socket is not disabled.

I was talking about whitelist, not (no)blacklist. That's a confusing difference in firejail. Anyway I checked and wruc is only in firefox-common.profile on master. If you add include whitelist-runuser-common.inc to your firefox.local, you will have the same.

But does this mean that an untrusted app could get the screen content without the user being aware of it?

Portals originate from flatpak and were developed with the intention to be exposed to a sandbox. Every flatpak can talk to org.freedesktop.portal.*.

Brief summary of their function: sandboxed program talks to org.freedesktop.portal.Desktop (that's the portal "frontend"). This request in forwarded by e.g. xdg-desktop-portal to e.g. org.freedesktop.impl.portal.desktop.gtk (that the portal backend). The program listening on org.freedesktop.impl.portal.ABC then displays a dialog/notification/... to the user.

[albinou]

Thanks for your explanation!

The program listening on org.freedesktop.impl.portal.ABC then displays a dialog/notification/... to the user.

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)?
Because I have no notification when sharing my screen :-/

[rusty-snake]

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).

(notification sent over DBUS to a notification daemon (like mako in my case)?

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.

[albinou]

Thank your very much for your screenshots, now I understand :-)

If the desktop-portal just allows everything, there is no advantage in using portal over direct access.

xdg-desktop-portal-wlr is a pretty new project and I think it is the only way to do screen-sharing under sway.

[Luticus]

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.

[glitsj16]

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.

@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.

[Luticus]

@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.

[Luticus]

@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.

[glitsj16]

@Luticus For reference, I found that info on the Arch Linux wiki. I'd be surprised if it changes anything related to this issue, that's why I used 'Unrelated note'...

[albinou]

@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 include whitelist-runuser-common.inc so I guess I don't have restrictions on data under the path ${RUNUSER}. This may explain why I don't need the whitelist ${RUNUSER}/pipewire-0 rule. I will try to run additional tests when I'll have some time.

[rusty-snake]

So to force FF to use Wayland that would be MOZ_ENABLE_WAYLAND=1.

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'm running firefox 85, wayland + KDE 5.20.5

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.)

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.

If you add whitelist ${RUNUSER}/pipewire-0 w/o include whitelist-runuser-common.inc you're missing the whitelist ${RUNUSER}/wayland-0. Without access to the wayland socket wayland doesn't work (understandable).

my /etc/firejail/firefox-common.profile file does not include whitelist-runuser-common.inc so I guess I don't have restrictions on data under the path ${RUNUSER}. This may explain why I don't need the whitelist ${RUNUSER}/pipewire-0 rule.

That's it, w/o wruc you has full* access to ${RUNUSER}

*the blacklist from disable-common.inc is still used

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.

Just use

ipc-namespace
blacklist /tmp/.X11-unix

[Luticus]

@rusty-snake

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:

ipc-namespace
blacklist /tmp/.x11-unix
dbus-user.talk org.freedesktop.impl.portal.desktop.kde
dbus-user.talk org.freedesktop.impl.portal.desktop.gtk
include whitelist-runuser-common.inc
whitelist ${RUNUSER}/pipewire-0
whitelist ${RUNUSER}/wayland-0

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.