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 #3673] bug? --rmenv seems to fire after check for length of environment variables, which makes long variables impossible to remove from firejail side #2312

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

Originally created by @MahouShoujoMivutilde on GitHub (Oct 15, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3673

First of all, thank you for this amazing tool, really enjoyed playing with it recently!

As for issue, there is not much to describe aside from the title, so here is

how to reproduce

steps

Let's set 2 short environment variables:

~ ❯ export AAAA=bbbb

~ ❯ export AAAA2=bbbb

~ ❯ firejail --rmenv="AAAA" env | grep -i aaaa
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 1352757, child pid 1352764
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Warning: cleaning all supplementary groups
Child process initialized in 88.72 ms
AAAA2=bbbb

Parent is shutting down, bye...

~ ❯ firejail --noprofile --rmenv="AAAA" env | grep -i aaaa
Parent pid 1354494, child pid 1354497
Child process initialized in 26.68 ms
AAAA2=bbbb

Parent is shutting down, bye...

As expected, AAAA is removed, and AAAA2 is available.

But now let's see what happens if we set AAAA to something really long.

~ ❯ export AAAA=$(tr -dc 'a-zA-Z0-9' < /dev/urandom | head -c 8000)

~ ❯ firejail --noprofile --rmenv="AAAA" env | grep -i aaaa
Error: too long environment variables

I expected same as in the first case to happen, but, as you can see, it just exits with error.

why even do this

My actual use case for it is removing LS_COLORS, which is generated by vivid and about is 8000 characters long.

I know about a workaround with alias as shown here, but LS_COLORS is also used by e.g. lf (which sometimes i launch just by itself, not from interactive shell), and my various scripts (which i usually call from sxhkd).

Of course, it's fixable even from my side, but i think it makes more sense for --rmenv to work before the length check.

That way, i could just add

rmenv LS_COLORS

to ~/.config/firejail/globals.local

And have just one LS_COLORS in .profile, instead of a bunch of local env LS_COLORS="$(vivid ...)" whatever or similar.

So what do you think? Is this expected behavior?

Environment

  • Arch linux, linux-zen 5.8.14, everything up-to-date.
  • Firejail version: 0ab64e277f (because i want new dbus stuff for firefox, because #3290 )

Checklist

  • The upstream profile (and redirect profile if exists) have no changes fixing it.
  • The program has a profile. (If not, request one in # 1139)
  • Programs needed for interaction are listed in the profile.
  • A short search for duplicates was performed.
  • If it is a AppImage, --profile=PROFILENAME is used to set the right profile.

...Behavior is not related to particular program, in regards to duplicates - i haven't seen anything about length check / --rmenv order.

debug output (with long AAAA) 
~ ❯ firejail --debug --rmenv="AAAA" env
Error: too long environment variables

(yes, there is nothing else)

EDIT:

Ops, i didn't actually need to use latest master to fix #3290.

Turns out, it's an error on my side - what i wanted to do is to have 2 separate isolated profiles with different configs and stuff, and naturally i used firefox with -no-remote flag, so two instances could run simultaneously.

And when i tried to open new links in one of them with firejail firefox -no-remote -p pr1 *link* - i was getting the same error, as in #3290.

After messing around in the middle of the night with a launch script (in which i wrapped conditional whitelisting and stuff) and upgrading to the latest master it eventually work, so i assumed that master fixed it and forgot about now missing -no-remote.

Turns out, when you run firefox in firejail, you can run two instances simultaneously without -no-remote.

Well, that's embarrassing. 😅

But i think original question about --rmenv / length checking order is still valid, since i (and probably other vivid users too) eventually will have to deal with it.

In case anyone wants the launching script - here it is:

fjfirefox 
#!/usr/bin/env sh

unset LS_COLORS

while [ "$#" -gt 0 ]; do
    case "$1" in
        -p)
            profile="$2"
            shift
            ;;
        -u)
            url="$2"
            shift
            ;;
        *)
            exit 1
            ;;
    esac
    shift
done

profile="${profile:-stable}"
# note that it assumes that profiles are in non default location.
# that way, you can whitelist only one profile and nothing else.
# cache also stored here, as you can check with about:cache
wlprof="$(fd -t d -d 1 "\.$profile$" . ~/.config/firefox-profiles)"

if [ -z "$url" ]; then
    firejail \
        --whitelist="$wlprof" \
        firefox-nightly -p "$profile"
else
    firejail \
        --whitelist="$wlprof" \
        firefox-nightly -p "$profile" "$url"
fi
Originally created by @MahouShoujoMivutilde on GitHub (Oct 15, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3673 First of all, thank you for this amazing tool, really enjoyed playing with it recently! As for issue, there is not much to describe aside from the title, so here is ### how to reproduce <details><summary> steps </summary> Let's set 2 short environment variables: ```sh ~ ❯ export AAAA=bbbb ~ ❯ export AAAA2=bbbb ``` ```sh ~ ❯ firejail --rmenv="AAAA" env | grep -i aaaa Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 1352757, child pid 1352764 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Warning: cleaning all supplementary groups Child process initialized in 88.72 ms AAAA2=bbbb Parent is shutting down, bye... ~ ❯ firejail --noprofile --rmenv="AAAA" env | grep -i aaaa Parent pid 1354494, child pid 1354497 Child process initialized in 26.68 ms AAAA2=bbbb Parent is shutting down, bye... ``` As expected, `AAAA` is removed, and `AAAA2` is available. But now let's see what happens if we set `AAAA` to something really long. ```sh ~ ❯ export AAAA=$(tr -dc 'a-zA-Z0-9' < /dev/urandom | head -c 8000) ~ ❯ firejail --noprofile --rmenv="AAAA" env | grep -i aaaa Error: too long environment variables ``` </details> I expected same as in the first case to happen, but, as you can see, it just exits with error. ### why even do this My actual use case for it is removing LS_COLORS, which is generated by [vivid](https://github.com/sharkdp/vivid) and about is 8000 characters long. I know about a workaround with alias as shown [here](https://github.com/netblue30/firejail/pull/3325#issuecomment-612673155), but LS_COLORS is also used by e.g. [lf](https://github.com/gokcehan/lf) (which sometimes i launch just by itself, not from interactive shell), and my various scripts (which i usually call from [sxhkd](https://github.com/baskerville/sxhkd)). Of course, it's fixable even from my side, but **i think it makes more sense for --rmenv to work before the length check.** That way, i could just add ``` rmenv LS_COLORS ``` to `~/.config/firejail/globals.local` And have just one LS_COLORS in .profile, instead of a bunch of local `env LS_COLORS="$(vivid ...)" whatever` or similar. So what do you think? Is this expected behavior? **Environment** - Arch linux, linux-zen 5.8.14, everything up-to-date. - Firejail version: 0ab64e277fc48c56b842e0639d450b3311038333 (because i want new dbus stuff for firefox, because #3290 ) **Checklist** - [ ] ~~The upstream profile (and redirect profile if exists) have no changes fixing it.~~ - [ ] ~~The program has a profile. (If not, request one in [# 1139](https://github.com/netblue30/firejail/issues/1139))~~ - [ ] ~~Programs needed for interaction are listed in the profile.~~ - [x] A short search for duplicates was performed. - [ ] ~~If it is a AppImage, `--profile=PROFILENAME` is used to set the right profile.~~ ...Behavior is not related to particular program, in regards to duplicates - i haven't seen anything about length check / --rmenv order. <details><summary> debug output (with long AAAA) </summary> ```sh ~ ❯ firejail --debug --rmenv="AAAA" env Error: too long environment variables ``` (yes, there is nothing else) </details> ## EDIT: Ops, i didn't actually need to use latest master to fix #3290. Turns out, it's an error on my side - what i wanted to do is to have 2 separate isolated profiles with different configs and stuff, and naturally i used firefox with -no-remote flag, so two instances could run simultaneously. And when i tried to open new links in one of them with `firejail firefox -no-remote -p pr1 *link*` - i was getting the same error, as in #3290. After messing around in the middle of the night with a launch script (in which i wrapped conditional whitelisting and stuff) and upgrading to the latest master it eventually work, so i assumed that master fixed it and forgot about now missing -no-remote. Turns out, when you run firefox in firejail, you can run two instances simultaneously without -no-remote. Well, that's embarrassing. :sweat_smile: But i think original question about --rmenv / length checking order is still valid, since i (and probably other vivid users too) eventually will have to deal with it. In case anyone wants the launching script - here it is: <details><summary> fjfirefox </summary> ```sh #!/usr/bin/env sh unset LS_COLORS while [ "$#" -gt 0 ]; do case "$1" in -p) profile="$2" shift ;; -u) url="$2" shift ;; *) exit 1 ;; esac shift done profile="${profile:-stable}" # note that it assumes that profiles are in non default location. # that way, you can whitelist only one profile and nothing else. # cache also stored here, as you can check with about:cache wlprof="$(fd -t d -d 1 "\.$profile$" . ~/.config/firefox-profiles)" if [ -z "$url" ]; then firejail \ --whitelist="$wlprof" \ firefox-nightly -p "$profile" else firejail \ --whitelist="$wlprof" \ firefox-nightly -p "$profile" "$url" fi ``` </details>
gitea-mirror 2026-05-05 09:00:08 -06:00
  • closed this issue
  • added the
    bug
         label
gitea-mirror commented 2026-05-05 09:00:11 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Oct 15, 2020):

Currently the environment variables are checked as early as possible, then config files are read, then program arguments including --rmenv and --env. It would make sense to handle --rmenv and --env specially before env var check. That way also env vars added by --env would be subject to the same restrictions.

<!-- gh-comment-id:709512969 --> @topimiettinen commented on GitHub (Oct 15, 2020): Currently the environment variables are checked as early as possible, then config files are read, then program arguments including `--rmenv` and `--env`. It would make sense to handle `--rmenv` and `--env` specially before env var check. That way also env vars added by `--env` would be subject to the same restrictions.
gitea-mirror commented 2026-05-05 09:00:12 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Oct 15, 2020):

This seems more tricky than I thought. It makes sense to process --rmenv early (and even remove the environment variables immediately), but --env is not so clear.

--rmenv and --env only apply to the sandboxed program, not to the main program of Firejail. Removing variables from the sandbox (and also from Firejail itself) should be safe. The length checks are made to protect Firejail as it's a set-uid program. But for the sandboxed program it should be OK to pass any kind of variables, so the checks shouldn't be necessary for them. Though similar length checks are also applied to arguments, which makes impossible to pass long variables with --env.

Maybe the argument length checks should be dropped for --env. But #3322 would remove most of the env variables from Firejail (they would still be passed to sandboxes), then the environment variable length checks could be made to apply only to those variables which are retained and the others could be any length.

<!-- gh-comment-id:709556815 --> @topimiettinen commented on GitHub (Oct 15, 2020): This seems more tricky than I thought. It makes sense to process `--rmenv` early (and even remove the environment variables immediately), but `--env` is not so clear. `--rmenv` and `--env` only apply to the sandboxed program, not to the main program of Firejail. Removing variables from the sandbox (and also from Firejail itself) should be safe. The length checks are made to protect Firejail as it's a set-uid program. But for the sandboxed program it should be OK to pass any kind of variables, so the checks shouldn't be necessary for them. Though similar length checks are also applied to arguments, which makes impossible to pass long variables with `--env`. Maybe the argument length checks should be dropped for `--env`. But #3322 would remove most of the env variables from Firejail (they would still be passed to sandboxes), then the environment variable length checks could be made to apply only to those variables which are retained and the others could be any length.
gitea-mirror commented 2026-05-05 09:00:13 -06:00
Author
Owner
Copy link

@MahouShoujoMivutilde commented on GitHub (Oct 15, 2020):

Wow, that was fast! Thank you for working on it.

I've built your PR against a3d415a1a4, and it seems to work, but only with --rmenv, not with rmenv inside config files.

here is a quick test 
~ ❯ export AAAA2=bbbb

~ ❯ cat ~/.config/firejail/globals.local
rmenv AAAA

~ ❯ export AAAA=bbbb

~ ❯ firejail env | grep -i aaaa
Reading profile /etc/firejail/default.profile
Reading profile /home/witch/.config/firejail/globals.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 677723, child pid 677725
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Warning: cleaning all supplementary groups
Child process initialized in 63.74 ms
AAAA2=bbbb

Parent is shutting down, bye...

As you can see, globals.local is read and applied as expected when AAAA is short.

~ ❯ export AAAA=$(tr -dc 'a-zA-Z0-9' < /dev/urandom | head -c 8000)

~ ❯ firejail env | grep -i aaaa
Error: too long environment variables

~ ❯ firejail --profile=default env | grep -i aaaa
Error: too long environment variables

But firejail still exits with an error when AAAA is long.

~ ❯ firejail --rmenv=AAAA env | grep -i aaaa
Reading profile /etc/firejail/default.profile
Reading profile /home/witch/.config/firejail/globals.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 681426, child pid 681428
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Warning: cleaning all supplementary groups
Child process initialized in 75.99 ms
AAAA2=bbbb

Parent is shutting down, bye...

~ ❯ firejail --noprofile --rmenv=AAAA env | grep -i aaaa
Parent pid 724839, child pid 724842
Child process initialized in 12.36 ms
AAAA2=bbbb

Parent is shutting down, bye...

--rmenv, however, now works as expected.

<!-- gh-comment-id:709610966 --> @MahouShoujoMivutilde commented on GitHub (Oct 15, 2020): Wow, that was fast! Thank you for working on it. I've built your PR against a3d415a1a40658632cbe21be2c06e149d8821bb0, and it seems to work, but only with --rmenv, not with rmenv inside config files. <details><summary> here is a quick test </summary> ```sh ~ ❯ export AAAA2=bbbb ~ ❯ cat ~/.config/firejail/globals.local rmenv AAAA ~ ❯ export AAAA=bbbb ~ ❯ firejail env | grep -i aaaa Reading profile /etc/firejail/default.profile Reading profile /home/witch/.config/firejail/globals.local Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 677723, child pid 677725 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Warning: cleaning all supplementary groups Child process initialized in 63.74 ms AAAA2=bbbb Parent is shutting down, bye... ``` As you can see, globals.local is read and applied as expected when AAAA is short. ```sh ~ ❯ export AAAA=$(tr -dc 'a-zA-Z0-9' < /dev/urandom | head -c 8000) ~ ❯ firejail env | grep -i aaaa Error: too long environment variables ~ ❯ firejail --profile=default env | grep -i aaaa Error: too long environment variables ``` But firejail still exits with an error when AAAA is long. ```sh ~ ❯ firejail --rmenv=AAAA env | grep -i aaaa Reading profile /etc/firejail/default.profile Reading profile /home/witch/.config/firejail/globals.local Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 681426, child pid 681428 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Warning: cleaning all supplementary groups Child process initialized in 75.99 ms AAAA2=bbbb Parent is shutting down, bye... ~ ❯ firejail --noprofile --rmenv=AAAA env | grep -i aaaa Parent pid 724839, child pid 724842 Child process initialized in 12.36 ms AAAA2=bbbb Parent is shutting down, bye... ``` --rmenv, however, now works as expected. </details>
gitea-mirror commented 2026-05-05 09:00:14 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Oct 16, 2020):

I see. The problem with rmenv in profiles is that the profiles are read during processing of program arguments where lots of other stuff also happens, so if the length check would be moved after that, it would be very late. Reading the profiles earlier is also not possible since profiles can be added also with --profile. So for that I'd rather finalize #3322 first, but since we're now closer to a new release, it may not be a good move to do that just now.

The error message could be more helpful and suggest using --rmenv. Maybe the long variables and program arguments could be even removed automatically with a warning, but Firejail would not need to exit. Removing excess variables or arguments could be too random.

<!-- gh-comment-id:710405400 --> @topimiettinen commented on GitHub (Oct 16, 2020): I see. The problem with `rmenv` in profiles is that the profiles are read during processing of program arguments where lots of other stuff also happens, so if the length check would be moved after that, it would be very late. Reading the profiles earlier is also not possible since profiles can be added also with `--profile`. So for that I'd rather finalize #3322 first, but since we're now closer to a new release, it may not be a good move to do that just now. The error message could be more helpful and suggest using `--rmenv`. Maybe the long variables and program arguments could be even removed automatically with a warning, but Firejail would not need to exit. Removing excess variables or arguments could be too random.
gitea-mirror commented 2026-05-05 09:00:15 -06:00
Author
Owner
Copy link

@MahouShoujoMivutilde commented on GitHub (Oct 16, 2020):

So for that I'd rather finalize #3322 first, but since we're now closer to a new release, it may not be a good move to do that just now.

Makes sense.

Maybe the long variables and program arguments could be even removed automatically with a warning, but Firejail would not need to exit. Removing excess variables or arguments could be too random.

But until #3322 is finished, wouldn't you always want to remove them anyway - so firejail will actually run?

If you decide to go this route - i think length check can be just a warning about dropped variables, but if, e.g. user also has too many variables - it's his job to clean them, and there should be an error.

But i get what you mean, as a quick fix a warning instead of error is maybe ok, but in a long run #3322 seems like is a way to go.

<!-- gh-comment-id:710502127 --> @MahouShoujoMivutilde commented on GitHub (Oct 16, 2020): > So for that I'd rather finalize #3322 first, but since we're now closer to a new release, it may not be a good move to do that just now. Makes sense. > Maybe the long variables and program arguments could be even removed automatically with a warning, but Firejail would not need to exit. Removing excess variables or arguments could be too random. But until #3322 is finished, wouldn't you always want to remove them anyway - so firejail will actually run? If you decide to go this route - i think length check can be just a warning about dropped variables, but if, e.g. user also has too many variables - it's his job to clean them, and there should be an error. But i get what you mean, as a quick fix a warning instead of error is maybe ok, but in a long run #3322 seems like is a way to go.
gitea-mirror commented 2026-05-05 09:00:15 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Oct 17, 2020):

I think the workarounds should be good enough for just now, the user could miss the warnings for removing and removing could cause other problems.

<!-- gh-comment-id:710777619 --> @topimiettinen commented on GitHub (Oct 17, 2020): I think the workarounds should be good enough for just now, the user could miss the warnings for removing and removing could cause other problems.
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#2312
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?