mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3872] Screen sharing configuration on wayland #2435
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2435
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @albinou on GitHub (Jan 5, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3872
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.
@albinou commented on GitHub (Jan 5, 2021):
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 commented on GitHub (Jan 6, 2021):
Just that line? In my tests also
whitelist ${RUNUSER}/pipewire-0(w/o you get the prompt, but the shared screen in empty) andignore noroot(which is known to break portals). See https://github.com/netblue30/firejail/pull/3766#issuecomment-738732173.dbus-user.talk org.freedesktop.portal.*are considered sandbox safe and could be allowed by default.@albinou commented on GitHub (Jan 8, 2021):
Sorry for the late answer.
norootis indeed set in my/etc/firejail/firefox-common.profilefile (ArchLinux, firejail 0.9.64-2).And I think
${RUNUSER}/pipewire-0is not blacklisted because firefox-common.profile only includesdisable-common.incand the pipewire socket is not disabled.But does this mean that an untrusted app could get the screen content without the user being aware of it?
Cheers!
@rusty-snake commented on GitHub (Jan 8, 2021):
Crazy, the first time I allow sharing it aborts immediately and the second allow always works.
I can confirm that it works with
noroot.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 addinclude whitelist-runuser-common.incto your firefox.local, you will have the same.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-portalto e.g.org.freedesktop.impl.portal.desktop.gtk(that the portal backend). The program listening onorg.freedesktop.impl.portal.ABCthen displays a dialog/notification/... to the user.@albinou commented on GitHub (Jan 8, 2021):
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)?
Because I have no notification when sharing my screen :-/
@rusty-snake commented on GitHub (Jan 8, 2021):
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.
@albinou commented on GitHub (Jan 8, 2021):
Thank your very much for your screenshots, now I understand :-)
xdg-desktop-portal-wlris a pretty new project and I think it is the only way to do screen-sharing under sway.@Luticus commented on GitHub (Jan 26, 2021):
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.
@ghost commented on GitHub (Jan 26, 2021):
@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 commented on GitHub (Jan 27, 2021):
@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 commented on GitHub (Jan 27, 2021):
@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.
@ghost commented on GitHub (Jan 27, 2021):
@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 commented on GitHub (Jan 27, 2021):
@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.incso I guess I don't have restrictions on data under the path${RUNUSER}. This may explain why I don't need thewhitelist ${RUNUSER}/pipewire-0rule. I will try to run additional tests when I'll have some time.@rusty-snake commented on GitHub (Jan 27, 2021):
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
whitelist ${RUNUSER}/pipewire-0w/oinclude whitelist-runuser-common.incyou're missing thewhitelist ${RUNUSER}/wayland-0. Without access to the wayland socket wayland doesn't work (understandable).That's it, w/o wruc you has full* access to ${RUNUSER}
*the blacklist from disable-common.inc is still used
Just use
@Luticus commented on GitHub (Jan 28, 2021):
@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:
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.
@Luticus commented on GitHub (Jan 28, 2021):
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.
@rusty-snake commented on GitHub (Jan 28, 2021):
FTR: The portal implementations at
org.freedesktop.impl.portal.*are never directly accessed by programs. Only the programs listening onorg.freedesktop.portal.*talk to the implementations.@albinou commented on GitHub (Feb 6, 2021):
@Luticus: My ArchLinux updated its firejail version and, FYI, I don't need to whitelist ${RUNUSER}/wayland-0
@rusty-snake commented on GitHub (Feb 7, 2021):
@ 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
whitelist ${RUNUSER}/pipewire-0. If you add it willpipewire-0be the only file in/run/user/$UID. Nowayland-0(Wayland),bus(D-Bus) orpulse/native(PulseAudio).If you use firejail >= 0.9.64 your firefox-common.profile has wruc and only file with a
whitelistcommand will be in/run/user/$UID. Then you need to addwhitelist ${RUNUSER}/pipewire-0.@rusty-snake commented on GitHub (Feb 8, 2021):
Summary: Wayland screen-sharing requires
dbus-user.talk org.freedesktop.portal.Desktopandwhitelist ${RUNUSER}/pipewire-0and maybeignore noroot(depending on portal impl?).So @albinou feel free to open a PR with something like
@albinou commented on GitHub (Feb 9, 2021):
I can't get to link my pull request :-/
So here is the link: https://github.com/netblue30/firejail/pull/3966
@albinou commented on GitHub (Feb 10, 2021):
The pull request has been merged. We can close this issue.
@alxjsn commented on GitHub (Jun 22, 2021):
To get xdg-desktop-portal-wlr working with Sway on Arch Linux I needed the following lines for these various browsers:
Firefox
Google Chrome
Chromium
@rusty-snake commented on GitHub (Jun 22, 2021):
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
dbus-user.talk org.freedesktop.portal.Desktopshouldn't make any differences.@albinou commented on GitHub (Jun 22, 2021):
Very nice, thanks @alxjsn !
It wasn't working anymore on my side too so it fixed it :)
I only needed to add the following line to my firefox and chromium config:
whitelist /usr/share/pipewire/client.conf@alxjsn: Do you want to propose a PR to add this (as comment) in config files? Or I can do it if you want.
Thanks!
@alxjsn commented on GitHub (Jun 22, 2021):
@albinou @rusty-snake created a PR here: https://github.com/netblue30/firejail/pull/4368
@reagentoo commented on GitHub (Nov 26, 2021):
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
net-im/telegram-desktop-3.2.4
sys-apps/firejail-0.9.66
sys-apps/xdg-desktop-portal-1.10.1
sys-apps/xdg-desktop-portal-gtk-1.8.0
www-client/firefox-94.0.2
x11-wm/mutter-41.1