github-starred/firejail
2
0
Fork 0
mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00
Code Issues 531 Projects Packages Wiki Activity Actions 6

[GH-ISSUE #6657] firecfg: gedit is not sandboxed (.desktop file) #3328

New issue
Closed
opened 2026-05-05 09:54:59 -06:00 by gitea-mirror · 10 comments
gitea-mirror commented 2026-05-05 09:54:59 -06:00
Owner
Copy link

Originally created by @ginto37 on GitHub (Feb 21, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6657

Description

gedit AKA TextEdit is not sandboxed with firejail if it is launched using the Search feature from the Activities/Overview mode in Ubuntu 22.04 LTS. It is sandboxed if launched from the Terminal with gedit.

Steps to Reproduce

Steps to reproduce the behavior

  1. Open Activities/Overview mode from the top panel or using the keyboard shortcut
  2. Search for TextEdit or gedit and launch it
  3. In a Terminal, check the output of firejail --list

Expected behavior

Output should be similar to the following:

3233:USERNAME::/usr/bin/firejail /usr/bin/gedit

Actual behavior

There is no output.

Behavior without a profile

N/A

Additional context

gedit AKA TextEdit is sandboxed if launched from the Terminal using gedit.

Environment

  • Name/version/arch of the Linux kernel (uname -srm): Linux 6.8.0-52-generic x86_64
  • Name/version of the Linux distribution (e.g. "Ubuntu 20.04" or "Arch Linux"): Ubuntu 22.04.5 LTS
  • Name/version of the relevant program(s)/package(s) (e.g. "firefox 134.0-1,
    mesa 1:24.3.3-2"): gedit 41.0
  • Version of Firejail (firejail --version): firejail version 0.9.72

Compile time support:
- always force nonewprivs support is disabled
- AppArmor support is enabled
- AppImage support is enabled
- chroot support is enabled
- D-BUS proxy support is enabled
- file transfer support is enabled
- firetunnel support is disabled
- IDS support is enabled
- networking support is enabled
- output logging is enabled
- overlayfs support is disabled
- private-home support is enabled
- private-cache and tmpfs as user enabled
- SELinux support is enabled
- user namespace support is enabled
- X11 sandboxing support is enabled

  • If you use a development version of firejail, also the commit from which it
    was compiled (git rev-parse HEAD):

Checklist

  • [N/A ] The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
  • [N/A ] I can reproduce the issue without custom modifications (e.g. globals.local).
  • [X ] The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
  • [N/A ] The profile (and redirect profile if exists) hasn't already been fixed upstream.
  • [X ] I have performed a short search for similar issues (to avoid opening a duplicate).
  • [N/A ] I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
  • [N/A ] I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Log

Output of LC_ALL=C firejail /path/to/program 

N/A

Output of LC_ALL=C firejail --debug /path/to/program 

N/A

Originally created by @ginto37 on GitHub (Feb 21, 2025). Original GitHub issue: https://github.com/netblue30/firejail/issues/6657 <!-- See the following links for help with formatting: https://guides.github.com/features/mastering-markdown/ https://docs.github.com/en/github/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax --> ### Description gedit AKA TextEdit is not sandboxed with firejail if it is launched using the Search feature from the Activities/Overview mode in Ubuntu 22.04 LTS. It _is_ sandboxed if launched from the Terminal with `gedit`. ### Steps to Reproduce _Steps to reproduce the behavior_ 1. Open Activities/Overview mode from the top panel or using the keyboard shortcut 2. Search for TextEdit or gedit and launch it 3. In a Terminal, check the output of `firejail --list` ### Expected behavior Output should be similar to the following: `3233:USERNAME::/usr/bin/firejail /usr/bin/gedit` ### Actual behavior There is no output. ### Behavior without a profile N/A ### Additional context gedit AKA TextEdit is sandboxed if launched from the Terminal using `gedit`. ### Environment - Name/version/arch of the Linux kernel (`uname -srm`): Linux 6.8.0-52-generic x86_64 - Name/version of the Linux distribution (e.g. "Ubuntu 20.04" or "Arch Linux"): Ubuntu 22.04.5 LTS - Name/version of the relevant program(s)/package(s) (e.g. "firefox 134.0-1, mesa 1:24.3.3-2"): gedit 41.0 - Version of Firejail (`firejail --version`): firejail version 0.9.72 Compile time support: - always force nonewprivs support is disabled - AppArmor support is enabled - AppImage support is enabled - chroot support is enabled - D-BUS proxy support is enabled - file transfer support is enabled - firetunnel support is disabled - IDS support is enabled - networking support is enabled - output logging is enabled - overlayfs support is disabled - private-home support is enabled - private-cache and tmpfs as user enabled - SELinux support is enabled - user namespace support is enabled - X11 sandboxing support is enabled - If you use a development version of firejail, also the commit from which it was compiled (`git rev-parse HEAD`): ### Checklist <!-- Note: Items are checked with an "x", like so: - [x] This is a checked item. --> - [N/A ] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [N/A ] I can reproduce the issue without custom modifications (e.g. globals.local). - [X ] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [N/A ] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [X ] I have performed a short search for similar issues (to avoid opening a duplicate). - [N/A ] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. - [N/A ] I used `--profile=PROFILENAME` to set the right profile. (Only relevant for AppImages) ### Log <details> <summary>Output of <code>LC_ALL=C firejail /path/to/program</code></summary> <p> ``` N/A ``` </p> </details> <details> <summary>Output of <code>LC_ALL=C firejail --debug /path/to/program</code></summary> <p> <!-- If the output is too long to embed it into the comment, create a secret gist at https://gist.github.com/ and link it here. --> ``` N/A ``` </p> </details>
gitea-mirror 2026-05-05 09:54:59 -06:00
gitea-mirror commented 2026-05-05 09:55:03 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Feb 21, 2025):

Works as intended.

0c791124a0/src/firecfg/firecfg.config (L330)

<!-- gh-comment-id:2674007372 --> @rusty-snake commented on GitHub (Feb 21, 2025): Works as intended. https://github.com/netblue30/firejail/blob/0c791124a083665848fa6e57a0d9677ca32d64a2/src/firecfg/firecfg.config#L330
gitea-mirror commented 2026-05-05 09:55:03 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Feb 21, 2025):

Relates to:

<!-- gh-comment-id:2674227158 --> @kmk3 commented on GitHub (Feb 21, 2025): Relates to: * #6002
gitea-mirror commented 2026-05-05 09:55:04 -06:00
Author
Owner
Copy link

@ginto37 commented on GitHub (Feb 25, 2025):

OK, if I'm reading this right, then there's a misunderstanding. I've uncommented gedit in /etc/firejail/firecfg.config.

When I wrote:

gedit AKA TextEdit is sandboxed if launched from the Terminal using gedit

I meant the following:

  1. Launch Terminal
  2. Type gedit
  3. Hit Enter

I think you're assuming I meant:

  1. Type firejail gedit

Am I right?

EDIT: Meant to add that VLC behaves the same way. It isn't sandboxed with firejail if I launch it from Activities view, but:

  1. Launch Terminal
  2. Type vlc
  3. Hit Enter

and it is.

<!-- gh-comment-id:2680949326 --> @ginto37 commented on GitHub (Feb 25, 2025): OK, if I'm reading this right, then there's a misunderstanding. I've uncommented `gedit` in `/etc/firejail/firecfg.config`. When I wrote: > gedit AKA TextEdit is sandboxed if launched from the Terminal using `gedit` I meant the following: 1. Launch Terminal 2. Type `gedit` 3. Hit Enter I think you're assuming I meant: 2. Type `firejail gedit` Am I right? EDIT: Meant to add that VLC behaves the same way. It isn't sandboxed with `firejail` if I launch it from Activities view, but: 1. Launch Terminal 2. Type `vlc` 3. Hit Enter and it is.
gitea-mirror commented 2026-05-05 09:55:05 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Feb 27, 2025):

Fixing desktop files in /home/USERNAME/.local/share/applications
   org.gnome.Nautilus.desktop skipped: file exists
   org.gnome.Logs.desktop skipped: file exists
   org.gnome.baobab.desktop skipped: file exists
   vlc.desktop skipped: file exists
   org.gnome.gedit.desktop skipped: file exists

OK, if I'm reading this right, then there's a misunderstanding. I've
uncommented gedit in /etc/firejail/firecfg.config.

EDIT: Meant to add that VLC behaves the same way. It isn't sandboxed with
firejail if I launch it from Activities view, but:

  1. Launch Terminal
  2. Type vlc
  3. Hit Enter

and it is.

Same as in the following comment:

What is the output of the following:

grep -R 'Exec=.*vlc' /usr/share/applications | LC_ALL=C sort -u
grep 'Exec=' ~/.local/share/applications/vlc.desktop
<!-- gh-comment-id:2688112934 --> @kmk3 commented on GitHub (Feb 27, 2025): > ``` > Fixing desktop files in /home/USERNAME/.local/share/applications > org.gnome.Nautilus.desktop skipped: file exists > org.gnome.Logs.desktop skipped: file exists > org.gnome.baobab.desktop skipped: file exists > vlc.desktop skipped: file exists > org.gnome.gedit.desktop skipped: file exists > ``` > OK, if I'm reading this right, then there's a misunderstanding. I've > uncommented `gedit` in `/etc/firejail/firecfg.config`. > EDIT: Meant to add that VLC behaves the same way. It isn't sandboxed with > `firejail` if I launch it from Activities view, but: > > 1. Launch Terminal > 2. Type `vlc` > 3. Hit Enter > > and it is. Same as in the following comment: * <https://github.com/netblue30/firejail/issues/6658#issuecomment-2681756618> What is the output of the following: ```sh grep -R 'Exec=.*vlc' /usr/share/applications | LC_ALL=C sort -u grep 'Exec=' ~/.local/share/applications/vlc.desktop ```
gitea-mirror commented 2026-05-05 09:55:05 -06:00
Author
Owner
Copy link

@ginto37 commented on GitHub (Mar 1, 2025):

$ grep -R 'Exec=.*vlc' /usr/share/applications | LC_ALL=C sort -u
/usr/share/applications/vlc.desktop:Exec=/usr/bin/vlc --started-from-file %U
/usr/share/applications/vlc.desktop:TryExec=/usr/bin/vlc

$ grep '^Exec' ~/.local/share/applications/vlc.desktop
grep: /home/USERNAME/.local/share/applications/vlc.desktop: No such file or directory
<!-- gh-comment-id:2691972015 --> @ginto37 commented on GitHub (Mar 1, 2025): ```console $ grep -R 'Exec=.*vlc' /usr/share/applications | LC_ALL=C sort -u /usr/share/applications/vlc.desktop:Exec=/usr/bin/vlc --started-from-file %U /usr/share/applications/vlc.desktop:TryExec=/usr/bin/vlc ``` ```console $ grep '^Exec' ~/.local/share/applications/vlc.desktop grep: /home/USERNAME/.local/share/applications/vlc.desktop: No such file or directory ```
gitea-mirror commented 2026-05-05 09:55:06 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Mar 1, 2025):

$ grep -R 'Exec=.*vlc' /usr/share/applications | LC_ALL=C sort -u
/usr/share/applications/vlc.desktop:Exec=/usr/bin/vlc --started-from-file %U
/usr/share/applications/vlc.desktop:TryExec=/usr/bin/vlc

$ grep '^Exec' ~/.local/share/applications/vlc.desktop
grep: /home/USERNAME/.local/share/applications/vlc.desktop: No such file or directory

Why was it removed?

It was clearly in your firecfg log:

Fixing desktop files in /home/USERNAME/.local/share/applications
   org.gnome.Nautilus.desktop skipped: file exists
   org.gnome.Logs.desktop skipped: file exists
   org.gnome.baobab.desktop skipped: file exists
   vlc.desktop skipped: file exists
   org.gnome.gedit.desktop skipped: file exists
<!-- gh-comment-id:2692205276 --> @kmk3 commented on GitHub (Mar 1, 2025): > ```console > $ grep -R 'Exec=.*vlc' /usr/share/applications | LC_ALL=C sort -u > /usr/share/applications/vlc.desktop:Exec=/usr/bin/vlc --started-from-file %U > /usr/share/applications/vlc.desktop:TryExec=/usr/bin/vlc > ``` > > ```console > $ grep '^Exec' ~/.local/share/applications/vlc.desktop > grep: /home/USERNAME/.local/share/applications/vlc.desktop: No such file or directory > ``` Why was it removed? It was clearly in your [firecfg log](https://github.com/netblue30/firejail/issues/6658#issuecomment-2681756618): > ``` > Fixing desktop files in /home/USERNAME/.local/share/applications > org.gnome.Nautilus.desktop skipped: file exists > org.gnome.Logs.desktop skipped: file exists > org.gnome.baobab.desktop skipped: file exists > vlc.desktop skipped: file exists > org.gnome.gedit.desktop skipped: file exists > ```
gitea-mirror commented 2026-05-05 09:55:07 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Mar 1, 2025):

Does it work if you do the following?

  • Backup and remove all .desktop files in ~/.local/share/applications
  • Reboot
  • Run sudo firecfg as your normal user
  • Reboot
<!-- gh-comment-id:2692395976 --> @kmk3 commented on GitHub (Mar 1, 2025): Does it work if you do the following? * Backup and remove all .desktop files in ~/.local/share/applications * Reboot * Run `sudo firecfg` as your normal user * Reboot
gitea-mirror commented 2026-05-05 09:55:07 -06:00
Author
Owner
Copy link

@ginto37 commented on GitHub (Mar 5, 2025):

$ grep -R 'Exec=.*vlc' /usr/share/applications | LC_ALL=C sort -u
/usr/share/applications/vlc.desktop:Exec=/usr/bin/vlc --started-from-file %U
/usr/share/applications/vlc.desktop:TryExec=/usr/bin/vlc

$ grep '^Exec' ~/.local/share/applications/vlc.desktop
grep: /home/USERNAME/.local/share/applications/vlc.desktop: No such file or directory

Why was it removed?

It was clearly in your firecfg log:

Fixing desktop files in /home/USERNAME/.local/share/applications
   org.gnome.Nautilus.desktop skipped: file exists
   org.gnome.Logs.desktop skipped: file exists
   org.gnome.baobab.desktop skipped: file exists
   vlc.desktop skipped: file exists
   org.gnome.gedit.desktop skipped: file exists

I've looked into this - I think I was still running as admin because of the earlier sudo firecfg so the output was for the wrong user. Replacing the username with USERNAME stopped this from becoming clear. I'll use ADMIN_USER and STANDARD_USER from now on respectively.

The output of ls -al ~/.local/share/applications/ for the standard user account shows that directory to be empty.

Does it work if you do the following?
Run sudo firecfg as your normal user

Removing all firejail symlinks:
	   seahorse removed
	   cvlc removed
	   ftp removed
	   transmission-gtk removed
	   gnome-logs removed
	   autokey-run removed
	   gnome-font-viewer removed
	   gcalccmd removed
	   evince-previewer removed
	   baobab removed
	   man removed
	   pdftotext removed
	   evince removed
	   autokey-shell removed
	   wget removed
	   gnome-characters removed
	   rhythmbox removed
	   autokey-gtk removed
	   strings removed
	   gnome-calculator removed
	   nslookup removed
	   eog removed
	   bleachbit removed
	   patch removed
	   firefox-esr removed
	   enchant-2 removed
	   xcalc removed
	   evince-thumbnailer removed
	   file-roller removed
	   gapplication removed
	   dnsmasq removed
	   gedit removed
	   dig removed
	   ping removed
	   rhythmbox-client removed
	   host removed
	   Xephyr removed
	   enchant-lsmod-2 removed
	   yelp removed
	   vlc removed

	Configuring symlinks in /usr/local/bin based on firecfg.config
	   Xephyr created
	   autokey-gtk created
	   autokey-run created
	   autokey-shell created
	   baobab created
	   bleachbit created
	   cvlc created
	   dig created
	   dnsmasq created
	   enchant-2 created
	   enchant-lsmod-2 created
	   eog created
	   evince created
	   evince-previewer created
	   evince-thumbnailer created
	   file-roller created
	   firefox-esr created
	   ftp created
	   gapplication created
	   gcalccmd created
	   gedit created
	   gnome-calculator created
	   gnome-characters created
	   gnome-font-viewer created
	   gnome-logs created
	   host created
	   man created
	   nslookup created
	   patch created
	   pdftotext created
	   ping created
	   rhythmbox created
	   rhythmbox-client created
	   seahorse created
	   strings created
	   transmission-gtk created
	   vlc created
	   wget created
	   xcalc created
	   yelp created

	Adding user STANDARD_USER to Firejail access database in /etc/firejail/firejail.users
	User STANDARD_USER already in the database

	Loading AppArmor profile

	Fixing desktop files in /home/STANDARD_USER/.local/share/applications
	   org.gnome.Nautilus.desktop created
	   org.gnome.Logs.desktop created
	   org.gnome.baobab.desktop created
	   vlc.desktop created
	   org.gnome.gedit.desktop created

After a reboot both TextEdit and VLC are sandboxed if launched from the Activities view of the standard user.

<!-- gh-comment-id:2700192025 --> @ginto37 commented on GitHub (Mar 5, 2025): > > $ grep -R 'Exec=.*vlc' /usr/share/applications | LC_ALL=C sort -u > > /usr/share/applications/vlc.desktop:Exec=/usr/bin/vlc --started-from-file %U > > /usr/share/applications/vlc.desktop:TryExec=/usr/bin/vlc > > > > > > $ grep '^Exec' ~/.local/share/applications/vlc.desktop > > grep: /home/USERNAME/.local/share/applications/vlc.desktop: No such file or directory > > Why was it removed? > > It was clearly in your [firecfg log](https://github.com/netblue30/firejail/issues/6658#issuecomment-2681756618): > > > ``` > > Fixing desktop files in /home/USERNAME/.local/share/applications > > org.gnome.Nautilus.desktop skipped: file exists > > org.gnome.Logs.desktop skipped: file exists > > org.gnome.baobab.desktop skipped: file exists > > vlc.desktop skipped: file exists > > org.gnome.gedit.desktop skipped: file exists > > ``` I've looked into this - I think I was still running as admin because of the earlier `sudo firecfg` so the output was for the wrong user. Replacing the username with USERNAME stopped this from becoming clear. I'll use ADMIN_USER and STANDARD_USER from now on respectively. The output of `ls -al ~/.local/share/applications/` for the standard user account shows that directory to be empty. > Does it work if you do the following? > Run `sudo firecfg` as your normal user ``` Removing all firejail symlinks: seahorse removed cvlc removed ftp removed transmission-gtk removed gnome-logs removed autokey-run removed gnome-font-viewer removed gcalccmd removed evince-previewer removed baobab removed man removed pdftotext removed evince removed autokey-shell removed wget removed gnome-characters removed rhythmbox removed autokey-gtk removed strings removed gnome-calculator removed nslookup removed eog removed bleachbit removed patch removed firefox-esr removed enchant-2 removed xcalc removed evince-thumbnailer removed file-roller removed gapplication removed dnsmasq removed gedit removed dig removed ping removed rhythmbox-client removed host removed Xephyr removed enchant-lsmod-2 removed yelp removed vlc removed Configuring symlinks in /usr/local/bin based on firecfg.config Xephyr created autokey-gtk created autokey-run created autokey-shell created baobab created bleachbit created cvlc created dig created dnsmasq created enchant-2 created enchant-lsmod-2 created eog created evince created evince-previewer created evince-thumbnailer created file-roller created firefox-esr created ftp created gapplication created gcalccmd created gedit created gnome-calculator created gnome-characters created gnome-font-viewer created gnome-logs created host created man created nslookup created patch created pdftotext created ping created rhythmbox created rhythmbox-client created seahorse created strings created transmission-gtk created vlc created wget created xcalc created yelp created Adding user STANDARD_USER to Firejail access database in /etc/firejail/firejail.users User STANDARD_USER already in the database Loading AppArmor profile Fixing desktop files in /home/STANDARD_USER/.local/share/applications org.gnome.Nautilus.desktop created org.gnome.Logs.desktop created org.gnome.baobab.desktop created vlc.desktop created org.gnome.gedit.desktop created ``` After a reboot both TextEdit and VLC are sandboxed if launched from the Activities view of the standard user.
gitea-mirror commented 2026-05-05 09:55:08 -06:00
Author
Owner
Copy link

@ginto37 commented on GitHub (Mar 7, 2025):

It looks like you're attributing this to user error. I checked the
installation steps in the README.md and in the video on YouTube, and it
doesn't indicate in either of those that it's necessary to run sudo firecfg from the user account where you'll be running the sandboxed
apps. To be fair, it doesn't explicitly indicate that you run it from
the admin account either. However, firecfg, at least for me, was /not/
automatically added to my standard user's sudoers permissions, and
this isn't stated as a manually required step in either of the places I
mentioned above, so it's reasonable to assume that the instruction is
referring to the admin user.

If sudo firecfg should always be run from the user account where
you'll be running the sandboxed apps, then either sudo firecfg should
be automatically added to that user's sudoers permissions during
installation (not ideal, IMO, for the usual security reasons) or there
should be an explicit instruction to that effect in the appropriate places.

But then again, I don't see why sudo firecfg running as the admin user
shouldn't be able to accomplish the same things without involving the
sudoers file.

If I've misunderstood the reason for closing this issue, let me know.

<!-- gh-comment-id:2705735010 --> @ginto37 commented on GitHub (Mar 7, 2025): It looks like you're attributing this to user error. I checked the installation steps in the README.md and in the video on YouTube, and it doesn't indicate in either of those that it's necessary to run `sudo firecfg` from the user account where you'll be running the sandboxed apps. To be fair, it doesn't explicitly indicate that you run it from the admin account either. However, `firecfg`, at least for me, was /not/ automatically added to my standard user's `sudoers` permissions, and this isn't stated as a manually required step in either of the places I mentioned above, so it's reasonable to assume that the instruction is referring to the admin user. If `sudo firecfg` should always be run from the user account where you'll be running the sandboxed apps, then either `sudo firecfg` should be automatically added to that user's `sudoers` permissions during installation (not ideal, IMO, for the usual security reasons) or there should be an explicit instruction to that effect in the appropriate places. But then again, I don't see why `sudo firecfg` running as the admin user shouldn't be able to accomplish the same things without involving the `sudoers` file. If I've misunderstood the reason for closing this issue, let me know.
gitea-mirror commented 2026-05-05 09:55:08 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Mar 7, 2025):

It looks like you're attributing this to user error.

Yes.

I checked the installation steps in the README.md and in the video on
YouTube, and it doesn't indicate in either of those that it's necessary to
run sudo firecfg from the user account where you'll be running the
sandboxed apps. To be fair, it doesn't explicitly indicate that you run it
from the admin account either. However, firecfg, at least for me, was /not/
automatically added to my standard user's sudoers permissions, and this
isn't stated as a manually required step in either of the places I mentioned
above, so it's reasonable to assume that the instruction is referring to the
admin user.

I don't think it's very common to have a separate admin-only account (other
than root), so that's probably why it's not mentioned.

The fact that it says sudo firecfg rather than just firecfg (and that
firecfg requires privileges) is an indicator that it should be executed as
a normal user rather than root (or another similar account).

Though that requirement indeed could be made more explicit, so thanks for
reporting it.

I created a PR to clarify that:

Also, as mentioned by @rusty-snake, note that it is possible to run
firecfg as root to add the global symlinks and then firecfg --fix as an
unprivileged user just to apply the desktop integration for that user.

If sudo firecfg should always be run from the user account where you'll be
running the sandboxed apps, then either sudo firecfg should be
automatically added to that user's sudoers permissions during installation
(not ideal, IMO, for the usual security reasons) or there should be an
explicit instruction to that effect in the appropriate places.

Note that firejail does not modify the sudoers file at all.

I don't think I'd expect any program to do so (other than the package manager),
especially since an invalid sudoers file could lead to the end user being
unable to perform privileged actions at all.

Kind of related to that, see the following in firejail(1) (added in #5290):

DESCRIPTION

[...]
Firejail is currently implemented as an SUID binary, which means that if a
malicious or compromised user account manages to exploit a bug in Firejail,
that could ultimately lead to a privilege escalation to root. To mitigate
this, it is recommended to only allow trusted users to run firejail (see
firejail-users(5) for details on how to achieve that). For more details on
the security/usability tradeoffs of Firejail, see: #4601
https://github.com/netblue30/firejail/discussions/4601

But then again, I don't see why sudo firecfg running as the admin user
shouldn't be able to accomplish the same things without involving the
sudoers file. If I've misunderstood the reason for closing this issue, let
me know.

firecfg only modifies .desktop files for the user running it, as not all users
may be able to run firejail and the end user may not want to create .desktop
file overrides in the home directory of all user accounts.

So to enable desktop integration for multiple users, run firecfg --fix as
each one of them.

<!-- gh-comment-id:2706324533 --> @kmk3 commented on GitHub (Mar 7, 2025): > It looks like you're attributing this to user error. Yes. > I checked the installation steps in the README.md and in the video on > YouTube, and it doesn't indicate in either of those that it's necessary to > run `sudo firecfg` from the user account where you'll be running the > sandboxed apps. To be fair, it doesn't explicitly indicate that you run it > from the admin account either. However, `firecfg`, at least for me, was /not/ > automatically added to my standard user's `sudoers` permissions, and this > isn't stated as a manually required step in either of the places I mentioned > above, so it's reasonable to assume that the instruction is referring to the > admin user. I don't think it's very common to have a separate admin-only account (other than root), so that's probably why it's not mentioned. The fact that it says `sudo firecfg` rather than just `firecfg` (and that `firecfg` requires privileges) is an indicator that it should be executed as a normal user rather than root (or another similar account). Though that requirement indeed could be made more explicit, so thanks for reporting it. I created a PR to clarify that: * #6677 Also, as [mentioned][1] by @rusty-snake, note that it is possible to run `firecfg` as root to add the global symlinks and then `firecfg --fix` as an unprivileged user just to apply the desktop integration for that user. > If `sudo firecfg` should always be run from the user account where you'll be > running the sandboxed apps, then either `sudo firecfg` should be > automatically added to that user's `sudoers` permissions during installation > (not ideal, IMO, for the usual security reasons) or there should be an > explicit instruction to that effect in the appropriate places. Note that firejail does not modify the sudoers file at all. I don't think I'd expect any program to do so (other than the package manager), especially since an invalid sudoers file could lead to the end user being unable to perform privileged actions at all. Kind of related to that, see the following in `firejail(1)` (added in #5290): > > DESCRIPTION > > > > [...] > > Firejail is currently implemented as an SUID binary, which means that if a > > malicious or compromised user account manages to exploit a bug in Firejail, > > that could ultimately lead to a privilege escalation to root. To mitigate > > this, it is recommended to only allow trusted users to run firejail (see > > firejail-users(5) for details on how to achieve that). For more details on > > the security/usability tradeoffs of Firejail, see: #4601 > > <https://github.com/netblue30/firejail/discussions/4601> > But then again, I don't see why `sudo firecfg` running as the admin user > shouldn't be able to accomplish the same things without involving the > `sudoers` file. If I've misunderstood the reason for closing this issue, let > me know. firecfg only modifies .desktop files for the user running it, as not all users may be able to run firejail and the end user may not want to create .desktop file overrides in the home directory of all user accounts. So to enable desktop integration for multiple users, run `firecfg --fix` as each one of them. [1]: https://github.com/netblue30/firejail/pull/6677#discussion_r1984936303
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
serialize_remounts_v2
landlock_v4
landlock
release-0.9.64
release-0.9.62
gitlab_ci
LTSbase
fred_ctests
docs
0.9.80
0.9.80-rc1
0.9.78
0.9.76
0.9.76-rc4
0.9.76-rc3
0.9.76-rc2
0.9.76-rc1
0.9.74
landlock-split
0.9.72
0.9.72rc1
0.9.70
0.9.68
0.9.68rc1
0.9.66
0.9.66rc1
0.9.64.4
0.9.64.2
0.9.64
0.9.64rc1
0.9.62.4
0.9.62.2
0.9.62
0.9.56.2-LTS
0.9.60
0.9.60-rc1
0.9.58.2
0.9.58
0.9.58-rc1
0.9.56-LTS-release
0.9.56-LTS
0.9.56
0.9.56-rc1
0.9.54
0.9.54-rc2
0.9.54-rc1
0.9.52
0.9.38.12
0.9.50
0.9.50-rc1
0.9.48
0.9.46
0.9.46-rc1
0.9.44.10
0.9.44.8
0.9.44.6
0.9.38.10
0.9.44.4
0.9.38.8
0.9.44.2
0.9.44
0.9.44-rc1
0.9.38.4
0.9.42
0.9.42-rc2
0.9.38.2
0.9.42-rc1
disable-globalcfg
0.9.40
0.9.40-rc1
0.9.38
0.9.38-rc1
0.9.36
0.9.36-rc1
0.9.34
0.9.34-rc1
0.9.32
0.9.32-rc1
0.9.30
0.9.30-rc1
Labels
Clear 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

Mirrored from GitHub Pull Request

  
question

   
question_old

   
removal

   
runtime-permissions

   
sandbox-ipc

   
security

   
stale

   
wiki

   
wiki

   
wontfix

   
wordpress

   
workaround
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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#3328
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?