[GH-ISSUE #4823] xed: cannot edit common blacklisted files

gitea-mirror commented

2026-05-05 09:26:36 -06:00

Owner

Originally created by @freedom4JA on GitHub (Jan 5, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4823

Configuration: Latest Firejail, Linux Mint 20.2, firecfg
Exp:
If I want to edit (with XED) firejail-profile in /.config --> red banner pops up " couldn't open file - you don't have requiered permissions"
whitelist the folder made no difference

Exp2:
If I want to edit firejail-profile in /etc (global) --> I can open a write-protected XY.profile but cannot safe it when i make a change inside
I would have to save it as a seperate file

Exp3:
If I copy a firejail XY.Profile in PICTURES i can open it but the content is invisible, I have a clean file without anything inside.
The same when I want to check syslog with XED

Originally created by @freedom4JA on GitHub (Jan 5, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/4823 Configuration: Latest Firejail, Linux Mint 20.2, firecfg Exp: If I want to edit (with XED) firejail-profile in /.config --> red banner pops up " couldn't open file - you don't have requiered permissions" whitelist the folder made no difference Exp2: If I want to edit firejail-profile in /etc (global) --> I can open a write-protected XY.profile but cannot safe it when i make a change inside I would have to save it as a seperate file Exp3: If I copy a firejail XY.Profile in PICTURES i can open it but the content is invisible, I have a clean file without anything inside. The same when I want to check syslog with XED

gitea-mirror

2026-05-05 09:26:36 -06:00

closed this issue
added the
notabug
label

gitea-mirror commented

2026-05-05 09:26:39 -06:00

Author

Owner

@freedom4JA commented on GitHub (Jan 5, 2022):

For the sake of completeness:
Editing ~/.bashrc the same as Exp 2
But ~/.bash_aliases same as Exp 3 (when trying to edit with XED Editor)

@freedom4JA commented on GitHub (Jan 5, 2022): For the sake of completeness: Editing ~/.bashrc the same as Exp 2 But ~/.bash_aliases same as Exp 3 (when trying to edit with XED Editor)

gitea-mirror commented

2026-05-05 09:26:40 -06:00

Author

Owner

@ghost commented on GitHub (Jan 5, 2022):

IMO this is a hardcoded limitation, see here. The same happens with nano. ${HOME}/.config/firejail is special, but I agree it doesn't seem to make much sense to force users into using a non-sandboxed editor to read-write that location. Will need more time to do research this to be sure though.

The above limitation only hits 'regular' (non-privileged) users it seems. I can use nano (started with sudo obviously) to read-write configuration files in /etc/firejail. Are you sure xed fails to do that when started with sudo as your Exp2 seems to imply?

@ghost commented on GitHub (Jan 5, 2022): IMO this is a hardcoded limitation, see [here](https://github.com/netblue30/firejail/blob/master/src/firejail/fs.c#L825). The same happens with `nano`. ${HOME}/.config/firejail is special, but I agree it doesn't seem to make much sense to force users into using a non-sandboxed editor to read-write that location. Will need more time to do research this to be sure though. The above limitation only hits 'regular' (non-privileged) users it seems. I can use nano (started with sudo obviously) to read-write configuration files in /etc/firejail. Are you sure xed fails to do that when started with sudo as your Exp2 seems to imply?

gitea-mirror commented

2026-05-05 09:26:41 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 5, 2022):

but I agree it doesn't seem to make much sense to force users into using a non-sandboxed editor to read-write that location.

If you allowing a program to control it's own sandbox configuration, where the sense of sandboxing?

@rusty-snake commented on GitHub (Jan 5, 2022): > but I agree it doesn't seem to make much sense to force users into using a non-sandboxed editor to read-write that location. If you allowing a program to control it's own sandbox configuration, where the sense of sandboxing?

gitea-mirror commented

2026-05-05 09:26:42 -06:00

Author

Owner

@ghost commented on GitHub (Jan 5, 2022):

If you allowing a program to control it's own sandbox configuration, where the sense of sandboxing?

Sure, I see and understand your argument. Still, letting a non-sandboxed program potentially control all sandbox configurations doesn't make much sense either. But perhaps I'm having one of those brain-fart days (still recovering from corona-blues during the end-of-year season :-p).

@ghost commented on GitHub (Jan 5, 2022): > If you allowing a program to control it's own sandbox configuration, where the sense of sandboxing? Sure, I see and understand your argument. Still, letting a `non-sandboxed` program potentially control `all` sandbox configurations doesn't make much sense either. But perhaps I'm having one of those brain-fart days (still recovering from corona-blues during the end-of-year season :-p).

gitea-mirror commented

2026-05-05 09:26:43 -06:00

Author

Owner

@ghost commented on GitHub (Jan 5, 2022):

For the sake of completeness:
Editing ~/.bashrc the same as Exp 2
But ~/.bash_aliases same as Exp 3 (when trying to edit with XED Editor)

Those bash files (and a whole lot of other sensitive files) are made read-only in disable-common.inc (# Startup files secrion). I'm NOT encouraging changing this, but if you want to, you can 'undo' this in a disable-common.local on a case-by-case basis. Example: ignore read-only ${HOME}/.bashrc. Or better yet, add 'ignore read-only ${HOME}/.bashrc' to a xed.local, so at least you minimize the hole...

@ghost commented on GitHub (Jan 5, 2022): > For the sake of completeness: Editing ~/.bashrc the same as Exp 2 But ~/.bash_aliases same as Exp 3 (when trying to edit with XED Editor) Those bash files (and a whole lot of other sensitive files) are made `read-only` in `disable-common.inc` (# Startup files secrion). I'm NOT encouraging changing this, but if you want to, you can 'undo' this in a `disable-common.local` on a case-by-case basis. Example: ignore read-only ${HOME}/.bashrc. Or better yet, add 'ignore read-only ${HOME}/.bashrc' to a `xed.local`, so at least you minimize the hole...

gitea-mirror commented

2026-05-05 09:26:43 -06:00

Author

Owner

@freedom4JA commented on GitHub (Jan 5, 2022):

The above limitation only hits 'regular' (non-privileged) users it seems. I can use nano (started with sudo obviously) to read-write configuration files in /etc/firejail. Are you sure xed fails to do that when started with sudo as your Exp2 seems to imply?

As su the xed (via terminal) editing and saving is working, when i only open it via terminal without su privilege its visible also but the saving problem still occur, when I edit it I got this output in the terminal:

(xed:7): Gtk-WARNING **: 18:40:47.943: Calling org.xfce.Session.Manager.Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method “Inhibit”

@freedom4JA commented on GitHub (Jan 5, 2022): > The above limitation only hits 'regular' (non-privileged) users it seems. I can use nano (started with sudo obviously) to read-write configuration files in /etc/firejail. Are you sure xed fails to do that when started with sudo as your Exp2 seems to imply? As su the xed (via terminal) editing and saving is working, when i only open it via terminal without su privilege its visible also but the saving problem still occur, when I edit it I got this output in the terminal: (xed:7): Gtk-WARNING **: 18:40:47.943: Calling org.xfce.Session.Manager.Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method “Inhibit”

gitea-mirror commented

2026-05-05 09:26:44 -06:00

Author

Owner

@ghost commented on GitHub (Jan 5, 2022):

As su the xed (via terminal) editing is working, when i only open it via terminal without su privilege its visible also but the saving problem still occur [...]

Keep in mind the general permissions logic here. It makes perfect sense to not let you save anything to a system-wide location without the needed privileges. That's not firejail related.

@ghost commented on GitHub (Jan 5, 2022): > As su the xed (via terminal) editing is working, when i only open it via terminal without su privilege its visible also but the saving problem still occur [...] Keep in mind the general permissions `logic` here. It makes perfect sense to not let you save anything to a system-wide location without the needed privileges. That's not firejail related.

gitea-mirror commented

2026-05-05 09:26:44 -06:00

Author

Owner

@freedom4JA commented on GitHub (Jan 5, 2022):

And to edit my custom-created .bash_aliases under HOME or any other textfile I don't can acces via XED nor via sudo XED,not even read-only. So only terminal->nano could edit all generated text-files. Or can I open e. g . ~/bash_aliases via XED when I edit the XED.local somehow

@freedom4JA commented on GitHub (Jan 5, 2022): And to edit my custom-created .bash_aliases under HOME or any other textfile I don't can acces via XED nor via sudo XED,not even read-only. So only terminal->nano could edit all generated text-files. Or can I open e. g . ~/bash_aliases via XED when I edit the XED.local somehow

gitea-mirror commented

2026-05-05 09:26:45 -06:00

Author

Owner

@kmk3 commented on GitHub (Sep 21, 2024):

xed has been disabled by default in firecfg in:

#6477

Otherwise, a program not being able to edit sensitive files like ~/.bashrc when
firejailed is the expected behavior.

For disabling specific programs in firecfg, see also:

#5876

@kmk3 commented on GitHub (Sep 21, 2024): xed has been disabled by default in firecfg in: * #6477 Otherwise, a program not being able to edit sensitive files like ~/.bashrc when firejailed is the expected behavior. For disabling specific programs in firecfg, see also: * #5876

Rows
Columns

[GH-ISSUE #4823] xed: cannot edit common blacklisted files #2786