github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1845] firejailed editor can't use sudoedit #1253

New issue

Closed

opened 2026-05-05 07:43:45 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 07:43:45 -06:00

Owner

Originally created by @chiraag-nataraj on GitHub (Mar 29, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1845

So in the interest of security, I decided to start sandboxing my editor (emacs). For day-to-day stuff, it works really well - I don't have any issues. However, I decided to try to use sudoedit to edit a configuration file, and the configuration file showed up blank. I suspected firejail was to blame, and looking at the output of firejail --ls=<pid> /var/tmp confirmed it - that directory was empty.

As far as I can tell, this is not configurable, which means launching an editor daemon within firejail will break sudoedit. For example, running firejail --noprofile --env=TMPDIR=/tmp/user/1000 emacs --daemon had the same problem - sudoedit would show me an empty file.

Would it be a good idea to allow whitelisting /var/tmp? Alternatively, is there a way to set the location of the sudoedit temp files?

Originally created by @chiraag-nataraj on GitHub (Mar 29, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1845 So in the interest of security, I decided to start sandboxing my editor (`emacs`). For day-to-day stuff, it works really well - I don't have any issues. However, I decided to try to use `sudoedit` to edit a configuration file, and the configuration file showed up blank. I suspected `firejail` was to blame, and looking at the output of `firejail --ls=<pid> /var/tmp` confirmed it - that directory was empty. As far as I can tell, this is not configurable, which means launching an editor daemon within `firejail` will break `sudoedit`. For example, running `firejail --noprofile --env=TMPDIR=/tmp/user/1000 emacs --daemon` had the same problem - `sudoedit` would show me an empty file. Would it be a good idea to allow whitelisting `/var/tmp`? Alternatively, is there a way to set the location of the `sudoedit` temp files?

gitea-mirror closed this issue

2026-05-05 07:43:47 -06:00

gitea-mirror commented

2026-05-05 07:43:50 -06:00

Author

Owner

@Vincent43 commented on GitHub (Mar 29, 2018):

You can use absolute path in SUDO_EDITOR variable, i.e. SUDO_EDITOR=/usr/bin/emacs. Then emacs will run unsandboxed when run within sudoedit but it will be sandboxed when you do day-to-day stuff.

@Vincent43 commented on GitHub (Mar 29, 2018): You can use absolute path in `SUDO_EDITOR` variable, i.e. `SUDO_EDITOR=/usr/bin/emacs`. Then emacs will run unsandboxed when run within `sudoedit` but it will be sandboxed when you do day-to-day stuff.

gitea-mirror commented

2026-05-05 07:43:52 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Mar 29, 2018):

Yeah, that's doable. But I'd definitely like to get this working, since the whole point of sudoedit is to be able to run the editor as my user, and there's no real reason not to sandbox that as I would with my regular editor. For example, I tried using whitelist /var/tmp to indicate to firejail that it should use the real /var/tmp directory, but the mount of /var/tmp happens before firejail checks the profile options, so whitelist /var/tmp basically has no effect. Shouldn't the default mounts be overrideable through the whitelist directive when appropriate? Or is this by design?

@chiraag-nataraj commented on GitHub (Mar 29, 2018): Yeah, that's doable. But I'd definitely like to get this working, since the whole point of `sudoedit` is to be able to run the editor as my user, and there's no real reason not to sandbox that as I would with my regular editor. For example, I tried using `whitelist /var/tmp` to indicate to `firejail` that it should use the real `/var/tmp` directory, but the mount of `/var/tmp` happens _before_ `firejail` checks the profile options, so `whitelist /var/tmp` basically has no effect. Shouldn't the default mounts be overrideable through the `whitelist` directive when appropriate? Or is this by design?

gitea-mirror commented

2026-05-05 07:43:54 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Mar 29, 2018):

So I looked through fs_var.c and fs.c a bit, and it seems that you're cleanly mounting /var/tmp to support multiple sandboxes (at least that's what the // update /var directory in order to support multiple sandboxes running on the same root directory implies?). But cleanly mounting /var/tmp seems to be a security measure, since none of the sandboxes have any files in there (I would presume mounting /var/lock is much more relevant to this aim). Can we have a setting that disables this (or just honor whitelist /var/tmp)?

@chiraag-nataraj commented on GitHub (Mar 29, 2018): So I looked through `fs_var.c` and `fs.c` a bit, and it seems that you're cleanly mounting `/var/tmp` to support multiple sandboxes (at least that's what the `// update /var directory in order to support multiple sandboxes running on the same root directory` implies?). But cleanly mounting `/var/tmp` seems to be a security measure, since none of the sandboxes have any files in there (I would presume mounting `/var/lock` is much more relevant to this aim). Can we have a setting that disables this (or just honor `whitelist /var/tmp`)?

gitea-mirror commented

2026-05-05 07:43:55 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Mar 29, 2018):

Okay, I hacked it in with a simple command-line option (--keep-var-tmp) and profile option (keep-var-tmp). It is handled in exactly the same way e.g. --writable-var-log is handled. Of course, it only really makes sense when used in conjunction with --writable-var, since the flag just disables the default behavior of overwriting /var/tmp. A patch file (suitable for git apply) is attached. What do people think?
keep-var-tmp.txt

@chiraag-nataraj commented on GitHub (Mar 29, 2018): Okay, I hacked it in with a simple command-line option (`--keep-var-tmp`) and profile option (`keep-var-tmp`). It is handled in exactly the same way e.g. `--writable-var-log` is handled. Of course, it only really makes sense when used in conjunction with `--writable-var`, since the flag just disables the default behavior of overwriting `/var/tmp`. A patch file (suitable for `git apply`) is attached. What do people think? [keep-var-tmp.txt](https://github.com/netblue30/firejail/files/1860260/keep-var-tmp.txt)

gitea-mirror referenced this issue

2026-05-05 10:09:59 -06:00

[PR #1253] [MERGED] Add overlay configuration to profiles #3898

No milestone

No project

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#1253

No description provided.

Rows
Columns