mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5032] chromium: file dialog does not work #2858
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#2858
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 @omega3 on GitHub (Mar 11, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5032
Discussed in https://github.com/netblue30/firejail/discussions/5025
Originally posted by omega3 March 9, 2022
Chromium doesn't allow to upload file for example to imgur. I am using Chromium on Plasma KDE. Imgur shows error.
When I add
nodbusit opens diffrent dialog, I guess it is gtk diolog - not Plasma KDE - and I can upload. But when I save file with this setting and this dialog I can't see them in Dolphin.What to do?
Expected behavior would be to be able to download / upload files in Chromium from Plasma KDE dialog and when downloaded, see them in Dolphin.
I use
chromium.localprofile, which is basically the same as in /etc/Firejail and run Chromium like this:firejail --private=/home/user/Data/jail/ --profile=/home/user/Data/jail/.config/firejail/chromium.local /usr/bin/chromiumI can download file from the Internet for example from Imgur to Downloads folder in this custom fake /home but at the same time I can't upload.
I added to
chromium.localbut it doesn't work.
Giving full path or something like this:
also doesn't work.
This doesn't work:
This doesn't work:
With this uploading works:
I am not sure about apparmor. I have it installed but as far I as remember I don't use it, perhaps I blocked it a long time ago. But Firefox works with default Firefox profile and upload works.
My chromium.local
@ghost commented on GitHub (Mar 11, 2022):
I'm not familiar with KDE but there's a comment on the last line in /etc/firejail/chromium-common.profile that you might try:
As a quick test you can add it without the conditional, just to double-check if you can get your Plasma tools working in the sandbox. Add the below line to your chromium.local and run your command again:
Does that change anything for the better?
@omega3 commented on GitHub (Mar 11, 2022):
I added like this:
env NO_CHROME_KDE_FILE_DIALOG=1both in/etc/firejail/chromium-common.profileandchromium.localand no change.@ghost commented on GitHub (Mar 12, 2022):
Might be a duplicate of https://github.com/netblue30/firejail/issues/4965.
Try adding the below to your /home/user/Data/jail/.config/firejail/chromium.local
@omega3 commented on GitHub (Mar 12, 2022):
It doesn't change anything. I need to rephrase this: "Expected behavior would be to be able to download / upload files in Chromium from Plasma KDE dialog and when downloaded, see them in Dolphin."
I don't care what dialog chromium uses gtk or KDE. The problem is that I can't see the filed downloaded with gtk dialog in Dolphin. I could see them that would solve the problem. Maybe I should install something in my system?
The other thing is that when I run Chromium without Firejail it uses KDE dialog and uploads files correctly. So, the conclusion is there is something in profiles or firejail that makes a difference.
@ghost commented on GitHub (Mar 12, 2022):
Does your dolphin run firejailed too?
You can transfer out the downloaded file(s) to your real filesystem for Dolphin:
What does the Imgur error say exactly?
@omega3 commented on GitHub (Mar 12, 2022):
https://i.imgur.com/QvsTaQt.png
No.
@ghost commented on GitHub (Mar 12, 2022):
I've put together a test profile to debug this. The private option is inside the file as you can see. Just to keep the command a bit shorter, shouldn't make any functional difference.
Please download this file, place it in your ~/Data/jail/.config/firejail dir as
fj-issue-5032.profileand run with the debug option:$ firejail --debug --profile=~/Data/jail/.config/firejail/fj-issue-5032.profile /usr/bin/chromium | tee -a ~/Downloads/fj-issue-5032.log. Try downloading/uploading, do some browsing etceterea and when you're done, upload the resulting ~/Downloads/fj-issue-5032.log somewhere (or post it here, as you prefer). I still cannot reproduce, but I don't have KDE (which shouldn't really matter here).@omega3 commented on GitHub (Mar 13, 2022):
With
fj-issue-5032.profileprofile file dialog within Chromium couldn't be open.https://i.imgur.com/1bnogBR.png
when I pressed "choose photo" nothing happened, no dialog appeared.
log and also output from terminal:
fj-issue-5032.log
The fact that dialog doesn't appear is caused by:
include chromium-common-hardened.inc.profilebut when I hashed it I still can't upload with above profile
@ghost commented on GitHub (Mar 14, 2022):
I'm out of ideas on this one. Copy chromium.profile and chromium-common.profile from /etc/firejail to your ~/Data/jail/.config/firejail and start commenting lines until you get a working configuration.
@Kebron718 commented on GitHub (Mar 20, 2022):
Hello omega3,
I've had the same problem with Chromium using openSUSE with KDE for a couple of months. Downloads only work directly into the downloads folder. Saving web pages only works using the print option. Uploads don’t work at all.
I found that uncommenting the noroot option in
/etc/firejail/chromium-common-hardened.inc.profile
does the trick for me.
However, I usually keep the noroot option enabled. I only disable it when I know that I want to upload something. Sometimes I just use Firefox instead in these rare occasions which has noroot enabled per default.
The hardened profile isn’t enabled per default in openSUSE. You have to manually uncomment the
include chromium-common-hardened.inc.profile
line in
/etc/firejail/chromium-common.profile
Maybe the noroot option is hidden somewhere else in one of the various profiles chromium uses.
@ghost commented on GitHub (Mar 21, 2022):
@Kebron718 That's some impressive detective work. Never suspected
norootcould have anything to do with uploading files in a web browser. But I'm not at all familiar with this one. Still, I wonder if any of you is using anything 'special' in ~/.config/chromium-flags.conf or wrapper scripts by any chance?The extra hardening is always disabled by default, regardless of distro.
No it's only in chromium-common-hardened.inc.profile AFAICT (it should be).
So a one-liner
ignore norootplaced in a~/.config/firejail/chromium-common-hardened.inc.localshould suffice for users facing this issue.@omega3 commented on GitHub (Mar 21, 2022):
Unfortunately, this didn't work for me.
This wiki shows many dbus options but I have no idea what they do.
https://man.archlinux.org/man/firejail.1.en
There was a discussion about dbus
Although I am not programmist I think that this issue may be connected to dbus options because with gtk dialog it works. The problem is how chromium in firejail "communicates" with kde system.
@ghost commented on GitHub (Mar 21, 2022):
Unfortunate to say the least.
The discussion you're refering to is now reality. Has been for a while. Firejail has integrated
xdg-dbus-proxy(you should install that package if it isn't!) and the 'newish' options are considered stable and pretty much feature-complete. This provides the much wanted finer-grained control earlier versions were missing. That implied implementing a more complex set of options to control D-Bus and I can see how that would need time to get familiar with. But in the case of chromium it's actually quite simple. By default chromium-common.profile grants full access to the D-Bus session bus and only blocks the system bus (which most programs don't need access to):We already discussed
NO_CHROME_KDE_FILE_DIALOG=1above and it didn't make any difference for your issue as you reported. So I see only one more thing you can try in this D-Bus context and that's granting full access to the system bus too.Most, if not all the DE-related files for both GTK and QT/KDE reside in the included *.inc files in the profile. To check if you need anything additional stuff, try not including any of those, just as a test to see if that changes anything. Together with the above D-Bus remarks that brings me to the below ~/.config/firejail/chromium-common.local:
Just make sure you don't have anything in globals.local and existing chromium{,-common}.local files that might throw sand in the machine.
@omega3 commented on GitHub (Mar 21, 2022):
It doesn't work.
the current setup is in
~/.config/firejail/:chromium-common-hardened.inc.local:
chromium-common.local:
chromium.local
@rusty-snake commented on GitHub (Mar 21, 2022):
File-dialog broken by
norooton KDE? Sounds like portals.@ghost commented on GitHub (Mar 21, 2022):
@rusty-snake Thanks for joining in. Obviously I don't understand the problem at hand and all I'm achieving here is confusing the OP. And myself for that matter. Twice already @omega3 said
ignore norootdoesn't work for him, here and here. Also, like mentioned above, chrome-common.profile doesn't filter dbus-user.norootcan still break things on KDE, regardless of D-Bus user options?@rusty-snake commented on GitHub (Mar 21, 2022):
Some xdg-desktop-portal implementations (in some versions) are broken (for some features) if the sandbox is started with
noroot(I known that at least some xdg-desktop-portal-kde versions are affected (under some configurations)). (As you see I don't really know when it happens just thatnoroot+ (some) xdg-desktop-portal impls + some conditions are broken). If chromium uses portals to get a native file-prompt, this may be an issue.@ghost commented on GitHub (Mar 21, 2022):
@rusty-snake Thanks for providing context and insights. Sounds a real mess :-) With that many unknowns (the multiple
some'sin your observations) it would be very difficult to formulate a working solution without flooding the affected profiles with even more comments. See {cachy-browser,firefox.librewolf}.profiles for examples of what I mean. The current count of advisory lines in the dbus section of those is13, not reassuring :-)@arrowgent commented on GitHub (Mar 29, 2022):
can confirm
norootportal issue with an Electron app when trying to open an "upload" dialog windowERROR:select_file_dialog_impl_portal.cc(698)] Portal returned error: org.freedesktop.DBus.Error.AccessDenied: Portal operation not allowed: Unable to open /proc/PID/rootapt list xdg-dbus-proxy
xdg-dbus-proxy/bionic,bionic,bionic,now 0.1.3-1~18.04 amd64 [installed,automatic]apt list xdg-desktop-portal
xdg-desktop-portal/bionic,bionic 1.12.1-1ubuntu1~18.04 amd64 [installed,automatic]apt list firejail
firejail/bionic,now 0.9.68-3~0ubuntu18.04.0 amd64 [installed]@AdamaTNT commented on GitHub (May 2, 2022):
I can also confirm that with Ubuntu 22.04 & using latest Google-Chrome, we are unable to upload anything as well.
I think one issue is that the --private=/folder is not being respected by all aspects of the jailed app, such as Gnome's file selection interface. On Ubuntu 20.04, when you used the open file dialog (CTRL+O), it would look like the opened location was the home folder of the user, while actually being the /folder it was jailed at. With 22.04, however, it always opens the actual $HOME folder and gives a list of all files and folders inside it, despite being unable to actually read any of the files when you try to open them.
Maybe what's happening is that there is some sort of a mismatch that prevents uploads: Gnome is sending one file location that uses the actual $HOME as a point of reference (which the jailed app doesn't have access), whereas the jailed app expects a file that matches the --private=/folder point of reference.
I thought this because, when trying to save files (as someone explained above), the only time a save succeeds is when the save targets $HOME/Downloads as selected by Gnome's file selection interface. All other attempts at saving at other locations fail. And when save succeeds, it actually saves to the jailed /folder/Downloads rather than the selected $HOME/Downloads in Gnome's file selection interface.
I have no real knowledge of the underlying infrastructure so I can't pinpoint the issue any further. This is just what I observe, maybe it will help.
Incidentally, the only error in the console output is:
Failed to connect to the bus: Failed to connect to socket /run/firejail/mnt/dbus/system: Permission denied
@rusty-snake commented on GitHub (May 2, 2022):
The document-portal does not support firejail (or firejail does not support the document-portal, take it as you like).
@marek22k commented on GitHub (May 27, 2024):
Hello,
I am also unable to upload files in Ungoogled Chromium when Firejail is enabled:
Is there a workaround?