mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5611] firefox: cursor does not unhide after moving (NixOS/sway) #3045
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#3045
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 @FarisFiroz on GitHub (Jan 22, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5611
Description
On a firejail sandboxed instance of firefox based browsers on swayWM, if the cursor is changed inside the browser, it has trouble changing back. This is most notable when the cursor is hidden such as when viewing a video. Once this happens, the cursor is forever hidden inside that window. Moving the cursor outside the window fixes it, but moving the cursor back inside the window breaks it.
Steps to reproduce
Expected Behavior: Mouse unhides after moving it.
Actual Behavior: Mouse continues to stay hidden after moving it.
Extra testing
Supplemental Information
Firejail version: 0.9.70
SwayWM version: 1.7
Distrobution: NixOS 22.11
@rusty-snake commented on GitHub (Jan 22, 2023):
Can you test with
--noprofile.@FarisFiroz commented on GitHub (Jan 22, 2023):
Yes, --noprofile allows for it to work as expected. I did just notice something though. I have a qt mouse when running with --noprofile or when not sand-boxed at all. However, when running with the librewolf.profile and firefox.profile, I do not. I believe this may be relevant.
@FarisFiroz commented on GitHub (Jan 22, 2023):
I checked the console and now see this:
but only when sandboxed with firejail using the librewolf profile. Thats a gtk error so honestly i'm a bit lost, maybe I was wrong in my last message about it being a qt cursor.
@ghost commented on GitHub (Jan 22, 2023):
See https://wiki.archlinux.org/title/Cursor_themes#Create_links_to_missing_cursors. In fact, that whole wiki page might be helpful to check. AFAIK mozilla browsers use GTK theming, so if you're using Qt cursor theme(s) this would make sense.
@FarisFiroz commented on GitHub (Jan 22, 2023):
I read through this, but unfortunately I am using nixOS and don't have a .icons directory at all. I did however do a check, I am using the breeze gtk theme and not the breeze qt theme. They look identical so I got a bit confused.
@rusty-snake commented on GitHub (Jan 22, 2023):
So the reason could be that the cursor icon isn't accessible by Firefox. Now the question is where is it installed or configured.
@FarisFiroz commented on GitHub (Jan 22, 2023):
Okay so here is what I have found so far:
The theme is stored in the /nix/store. This is where all packages in nixOS are stored. (This may be different if using home-manager, but I am not.)
The good thing is, every node in the nix-store is immutable so I don't believe allowing read access to them from a container/sandbox poses any security risk.
That being said, It does mean that someone who is willing to look through my store can read the different packages, derivations, etc. that I have built, so it's not exactly the "best" solution.
@FarisFiroz commented on GitHub (Jan 22, 2023):
Update: Allowing read-write access to the nix-store and nix-var does not fix anything
@kmk3 commented on GitHub (Jan 22, 2023):
Does this happen with firejail 0.9.72?
This does indeed seem like a path-related issue, so try disabling/commenting
all whitelist commands (for example, in librewolf.profile) to see if it works.
Then re-enable one by one to see which one breaks it.
If it does not change anything, considering that
--noprofileworks, trydoing the above for all commands in the profile (and included profiles).
@FarisFiroz commented on GitHub (Jan 22, 2023):
It seems that uncommenting the inclusion of the Firefox.profile does do "something". It is able to find a theme. With that being said, this is not breeze-dark(my theme), I have no idea where it is getting this data from. That being said, this is an improvement from not having a theme whatsoever. I will look more into firefox.profile to see what is breaking from inside that.
@FarisFiroz commented on GitHub (Jan 22, 2023):
Unfortunately, nix packages doesn't have 0.9.72 even on the unstable branch.
@FarisFiroz commented on GitHub (Jan 22, 2023):
I have found the issue.
The line
breaks things.
Moreover
is not valid according to the errors I'm getting.
Will now look into whitelist-run-common.inc.
@FarisFiroz commented on GitHub (Jan 22, 2023):
So it seems that trying to whitelist anything from the /run directory on nixos breaks things. I have tried to read and understand the debug log but I don't understand what's wrong. I have attached the debug output below.
output.txt
@ghost commented on GitHub (Jan 23, 2023):
We already
ignore apparmorin librewolf.profile. To me it makes sense to alsoignore apparmor-replacethere. You could open a PR for that. Before doing so it might help if you could show the errors from which you conclude it 'is not valid'. I can't see anything related to AppArmor in your attached output.txt.Also, as indicated by your output.txt there are several overrides (*.local files that get included too) in play here. I'm not suggesting there's something wrong with that. But it makes debugging this slightly more difficult without seeing their content. Please post those as well.
@FarisFiroz commented on GitHub (Jan 23, 2023):
Apologies, I uncommented apparmor-replace. Here is my error:
Unfortunately, I have not set up any overrides, it must be nixos's doing. The only thing that I have done is copy paste the profiles into my home folder so I can edit them. (They are immutable by default due to nixos).
Just FYI, I uncommented most of the files in whitelist-run-common.inc when taking this output I was uncommenting and recommenting things as needed, I will set everything to default and take another output.
@ghost commented on GitHub (Jan 23, 2023):
Thank you for this info. Regarding
apparmor-replace. That was introduced after 0.9.70 was released, so the error looks correct. I'm not familiar with nixos, nor with the way it packages Firejail. But seeing newer profiles mixed into an older release isn't exactly reassuring. If it was me I'd report such things on a OS bug tracker.Alas, I'm clueless at the moment on how to proceed here to fix the issue. Hopefully you can find something to drop from or add to whitelist-run-common.inc.
@FarisFiroz commented on GitHub (Jan 23, 2023):
This is my fault, It's difficult to find the immutable /etc/ specifically for the package and I found it easier to download the necessary files from the repo. I apologize.
I've included the other output directly using the immutable etc for the package.
output.txt
@ghost commented on GitHub (Jan 23, 2023):
No worries, that can happen. You're not the first one to try newer profiles on an older release to fix a problem. Just keep in mind that this is likely to create incompatibility issues and is not advised.
In this context we can ignore the VA-API part. Does librewolf 109.0 throw the same console error when started without firejail? The
execvp argument 0: /nix/store/ni0fhr4sxyxx9l627dpzzqss4842iwvq-librewolf-109.0-1/bin/librewolfindicates no URI was fed to it. Why it would complain about a malformed URI in such case is beyond me. What happens when you run it with https://example.org (or any other specific one you use regularly)?@FarisFiroz commented on GitHub (Jan 23, 2023):
Yes this is not an issue with firejail. It seems to do this regardless of if I put a valid URL in. Either way, this doesn't seem to inhibit the usability of the program.
@kmk3 commented on GitHub (Jan 23, 2023):
@glitsj16 on Jan 23:
FWIW I get similar errors on Artix and the program seems to work fine (though
I'm not using any special themes). I think that these specific ones started on
109, but librewolf has been printing weird JS errors on startup for a while.
@ghost commented on GitHub (Jan 23, 2023):
@kmk3 Thanks for these de-confusing details on latest librewolf :-)
It would be nice to find out if indeed
whitelist-run-common.incis (fully) broken onnixos. But at the moment I'm unable to install a third OS on my laptop to play around with it.@FarisFiroz commented on GitHub (Jan 24, 2023):
It is not "fully" broken as far as I can tell. whitelist-run-common.inc works fine(minus the cursor issue) when using the default firefox-common.profile in the immutable /etc. Unfortunately, it seems to fully break the minute I am using a firefox-common.profile not in the package's immutable /etc.
@ghost commented on GitHub (Jan 24, 2023):
Can you create per-user overrides in ${HOME}/.config/firejail? In other words, you do have access to Firejail's overrides functionality on nixos, correct? Although syntactically different, the below should all have the same result.
Or
Or
@FarisFiroz commented on GitHub (Jan 26, 2023):
does nothing.
@ghost commented on GitHub (Jan 26, 2023):
Glad to hear your overrides are being loaded. Less happy about the mistake I made :-) It should be
ignore include whitelist-run-common.inc! My apologies. I've edited the examples with the correct option.@FarisFiroz commented on GitHub (Jan 27, 2023):
No worries, it's nice to see that I can finally get back to debugging the issue.
Anyways yes, putting the new setting into firefox-common.local has the same behavior as using custom profiles.
@graham00 commented on GitHub (Aug 10, 2025):
I had a similar issue (on NixOS) with ungoogled-chromium, using chromium-browser.profile, where my cursor was tiny when interacting with chromium windows (it wasn't picking up the larger gnome cursor I had configured). I found this thread and added
--ignore="include whitelist-run-common.inc"and my cursor was back to normal.I also tried locally overriding whitelist-run-common.inc and commenting all the lines out but one. It didn't matter which one I left...whether it was a path that existed or not, if 100% of the whitelist statements in there weren't commented out, the problem would occur.
Strangely, I also run librewolf, and librewolf.profile by default calls whitelist-run-common.inc as well, but in its case, my cursor was perfectly fine.
Was something perhaps done in the intervening years that fixed this for firefox, but left a cursor/whitelist-run-common.inc/?nixos? related issue for chromium? @FarisFiroz - are you still experiencing the cursor issue now with firefox, if you remove your ignore statement?
@kmk3 commented on GitHub (Aug 10, 2025):
This is how whitelisting currently works: Any
whitelistcommand enableswhitelisting for the relevant base directory.
What is the output of the following (similarly to #6843)?
(Replace
/usr/bin/chromiumwith whatever the path is on NixOS)@graham00 commented on GitHub (Aug 10, 2025):
The fjtrace.txt was 0 bytes, and the strace produced a 5MB file - not sure how best to get that linked here, however...
Oh that's right, thanks! That clued me in to try whitelisting everything in /run item by item and selectively pairing down till I figured out what was causing the problem.
Adding the following fixes things:
--whitelist=/run/current-system/swApparently that's where NixOS keeps the equivalent of /usr/bin,/usr/sbin,/usr/share,etc, in a read-only overlay mount. (I'm still new to NixOS)
How much does having the non-FHS paths not covered by the default firejail profiles compromise its effective security in nixos?
@kmk3 commented on GitHub (Aug 13, 2025):
You can just click below the comment or drag and drop a file into it to upload
the file:
I see, nice that at least it works.
Maybe the NixOS paths could be conditionally added to macros when building on
NixOS.
This could work for macros like
${PATH}, though macros for other system pathsare currently missing (such as
${LIB}or${ETC}) so it would be better torefactor the related code and add those first.
See also:
No idea, you'd have to check what is in those directories and how NixOS handles
them.
In general, it seems that it would at least partly negate the security of
whitelisting certain system paths (such as for
private-binandprivate-etc).It would likely be a lot of work, but for the time being you could also look at
what is whiteslited in firefox.profile/firefox-common.profile and try to
whitelist more specific directories (instead of the entire
/run/current-system/sw) until it works, such as:Without NixOS paths in private-etc groups it might be a bit repetitive to
whitelist paths in etc/.
Whitelisting lib/ is usually tricky, so it might be useful to whitelist all of
lib/.
You'd also likely need to add NixOS paths to whitelist-usr-share-common.local
and so on.
Alternatively, try to hack firejail to add hardcoded NixOS paths where needed
and build it manually.