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 #3678] Error: too long environment variables, please use --rmenv #2314

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

Originally created by @simonfxr on GitHub (Oct 18, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3678

I just ran into this error.

My LS_COLORS env var is rather big (~5kb), which lead to:
Error: too long environment variables, please use --rmenv

I also can not work around the problem by passing --rmenv=LS_COLORS setting rmenv LS_COLORS in globals.local does also not work.
The problem is that calling unsetenv(*ptr) in main does not modify the envp passed to main(), extern char ** environ; should be used instead. Also I guess, that the profile is loaded after the check, so setting it in a profile won't work. Maybe this should be supported?

Also I don't understand what this check is trying to accomplish, any explanation would be appreciated.

For now I can just increase the limit by patching and recompiling myself.

Originally created by @simonfxr on GitHub (Oct 18, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3678 I just ran into this error. My LS_COLORS env var is rather big (~5kb), which lead to: `Error: too long environment variables, please use --rmenv` I also can not work around the problem by passing `--rmenv=LS_COLORS` setting `rmenv LS_COLORS` in globals.local does also not work. The problem is that calling `unsetenv(*ptr)` in main does not modify the `envp` passed to `main()`, `extern char ** environ;` should be used instead. Also I guess, that the profile is loaded after the check, so setting it in a profile won't work. Maybe this should be supported? Also I don't understand what this check is trying to accomplish, any explanation would be appreciated. For now I can just increase the limit by patching and recompiling myself.
gitea-mirror commented 2026-05-05 09:00:19 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Oct 18, 2020):

Also I don't understand what this check is trying to accomplish, any explanation would be appreciated.

There is more detailed info on protecting against stack smashing attack in https://github.com/netblue30/firejail/pull/3325, including a few other things you might try.

For now I can just increase the limit by patching and recompiling myself.

While patching and recompiling might 'fix' your issue, please be aware of the potential pitfalls of doing so in this context. The thread referenced above should provide a safer way out for your LS_COLORS issue.

<!-- gh-comment-id:711288207 --> @ghost commented on GitHub (Oct 18, 2020): > Also I don't understand what this check is trying to accomplish, any explanation would be appreciated. There is more detailed info on protecting against `stack smashing attack` in https://github.com/netblue30/firejail/pull/3325, including a few other things you might try. > For now I can just increase the limit by patching and recompiling myself. While patching and recompiling might 'fix' your issue, please be aware of the potential pitfalls of doing so in this context. The thread referenced above should provide a safer way out for your LS_COLORS issue.
gitea-mirror commented 2026-05-05 09:00:21 -06:00
Author
Owner
Copy link

@simonfxr commented on GitHub (Oct 18, 2020):

@glitsj16 Thx for the link, that makes sense. However that still does not address the problem with the --rmenv flag logic, that patch in #3674 does not work, since the loop over the env variable uses the envp argument, afaict the contents of envp are not modified by unsetenv() (see OP). Maybe it would be a better idea, to guard against the total environment size and not the size of single env entries.

<!-- gh-comment-id:711292010 --> @simonfxr commented on GitHub (Oct 18, 2020): @glitsj16 Thx for the link, that makes sense. However that still does not address the problem with the `--rmenv` flag logic, that patch in #3674 does not work, since the loop over the env variable uses the `envp` argument, afaict the contents of `envp` are not modified by `unsetenv()` (see OP). Maybe it would be a better idea, to guard against the total environment size and not the size of single env entries.
gitea-mirror commented 2026-05-05 09:00:22 -06:00
Author
Owner
Copy link

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

There's also some info on #3350. I think the proper fix to finalize #3322. Then the environment for Firejail itself is controlled and only a very small number of whitelisted, length checked variables are allowed inside the set-uid program. The variables are restored for the application itself and then the length checks could be relaxed. But even if #3322 was ready, I don't think it would be a good idea to push it just now when we're close to release.

Checking total environment size is a nice idea. Now we allow 256*(4096B+32B) = ~1MB of variables, when in reality maybe 64kB could be plenty while still allowing more or larger variables. Though this would be obsolete with #3322.

<!-- gh-comment-id:711341570 --> @topimiettinen commented on GitHub (Oct 18, 2020): There's also some info on #3350. I think the proper fix to finalize #3322. Then the environment for Firejail itself is controlled and only a very small number of whitelisted, length checked variables are allowed inside the set-uid program. The variables are restored for the application itself and then the length checks could be relaxed. But even if #3322 was ready, I don't think it would be a good idea to push it just now when we're close to release. Checking total environment size is a nice idea. Now we allow 256*(4096B+32B) = ~1MB of variables, when in reality maybe 64kB could be plenty while still allowing more or larger variables. Though this would be obsolete with #3322.
gitea-mirror commented 2026-05-05 09:00:23 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Nov 9, 2020):

So #3322 fixes this, right?

<!-- gh-comment-id:724227041 --> @rusty-snake commented on GitHub (Nov 9, 2020): So #3322 fixes this, right?
gitea-mirror commented 2026-05-05 09:00:24 -06:00
Author
Owner
Copy link

@topimiettinen commented on GitHub (Nov 10, 2020):

I prefer #3322, because it protects Firejail fully but it also allows applications to get less restricted environment. To finalize it, I still have to check all paths where Firejail executes something to ensure that the set of env variables is correct for each case.

<!-- gh-comment-id:724777957 --> @topimiettinen commented on GitHub (Nov 10, 2020): I prefer #3322, because it protects Firejail fully but it also allows applications to get less restricted environment. To finalize it, I still have to check all paths where Firejail executes something to ensure that the set of env variables is correct for each case.
gitea-mirror commented 2026-05-05 09:00:25 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 4, 2021):

I also ran into the same error message using the git command what is pretty strange since there is no profile for git in /etc/firejail/ nor anywhere else in my home. Next thing is git status works as usual

$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

but git pull returns

$ git pull
Error: too long environment variables, please use --rmenv
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

so there must be firejail working in the background when I use git pull. I ran git pull with strace

git pull.strace

and git status

git status.strace

The main difference I've found so far is the last call before the error happens in the git pull.strace file: The file /usr/lib/git-core/git is called which is a link to /usr/bin/git on my system

$ ll /usr/lib/git-core/git
lrwxrwxrwx 1 root root 13 Mar 27 09:27 /usr/lib/git-core/git -> ../../bin/git

I don't know why this error happens, at all. Ok my PS1 and _OLD_VIRTUAL_PS1 variables are pretty long which produce a beautiful prompt I really want to keep. Running

$ firejail --rmenv=PS1 --rmenv=_OLD_VIRTUAL_PS1 /usr/bin/git pull
Already up to date.

works as expected. But this doesn't explain why firejail is involved in the plain git pull command but not in git status. I don't see why firejail is involved at all running git. firecfg --list | grep git also doesn't return anything.

My setup

apparmor (3.0.1)

$ firejail --rmenv=PS1 --rmenv=_OLD_VIRTUAL_PS1 --version
firejail version 0.9.64.4

Compile time support:
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

yes running firejail --version also complains about the Error: too long environment variables, please use --rmenv

OS=Archlinux with kernel 5.10.27

$ which git
/usr/bin/git
$ git --version
git version 2.31.1

git --version works fine

<!-- gh-comment-id:813118793 --> @ghost commented on GitHub (Apr 4, 2021): I also ran into the same error message using the `git` command what is pretty strange since there is no profile for git in `/etc/firejail/` nor anywhere else in my home. Next thing is `git status` works as usual ```bash $ git status On branch master Your branch and 'origin/master' have diverged, and have 1 and 1 different commits each, respectively. (use "git pull" to merge the remote branch into yours) nothing to commit, working tree clean ``` but `git pull` returns ``` $ git pull Error: too long environment variables, please use --rmenv fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ``` so there must be firejail working in the background when I use `git pull`. I ran `git pull` with strace [git pull.strace](https://github.com/netblue30/firejail/files/6255608/gp.log) and `git status` [git status.strace](https://github.com/netblue30/firejail/files/6255613/gs.log) The main difference I've found so far is the last call before the error happens in the `git pull.strace` file: The file `/usr/lib/git-core/git` is called which is a link to /usr/bin/git on my system ```bash $ ll /usr/lib/git-core/git lrwxrwxrwx 1 root root 13 Mar 27 09:27 /usr/lib/git-core/git -> ../../bin/git ``` I don't know why this error happens, at all. Ok my PS1 and _OLD_VIRTUAL_PS1 variables are pretty long which produce a beautiful prompt I really want to keep. Running ```bash $ firejail --rmenv=PS1 --rmenv=_OLD_VIRTUAL_PS1 /usr/bin/git pull Already up to date. ``` works as expected. But this doesn't explain why firejail is involved in the plain `git pull` command but not in `git status`. I don't see why firejail is involved at all running `git`. `firecfg --list | grep git` also doesn't return anything. ------------ ### My setup apparmor (3.0.1) ```bash $ firejail --rmenv=PS1 --rmenv=_OLD_VIRTUAL_PS1 --version firejail version 0.9.64.4 Compile time support: - AppArmor support is enabled - AppImage support is enabled - chroot support is enabled - D-BUS proxy support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - firetunnel support is enabled - networking support is enabled - overlayfs support is disabled - private-home support is enabled - private-cache and tmpfs as user enabled - SELinux support is disabled - user namespace support is enabled - X11 sandboxing support is enabled ``` yes running `firejail --version` also complains about the `Error: too long environment variables, please use --rmenv` OS=Archlinux with kernel 5.10.27 ``` $ which git /usr/bin/git $ git --version git version 2.31.1 ``` `git --version` works fine
gitea-mirror commented 2026-05-05 09:00:25 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 5, 2021):

firejail version 0.9.64.4
no profile for git in /etc/firejail/ nor anywhere else in my home

@MaelStor Odd indeed. Firejail has had a git.profile for a while now, and it definately is in the 0.9.64.4 package on Arch. Can you confirm there is no /etc/firejail/git.profile on your system? Also, what does which -a git show? Try setting quiet-by-default yes in /etc/firejail/firejail.config temporarily to make output from a firejailed git stand out more prominently.

<!-- gh-comment-id:813125674 --> @ghost commented on GitHub (Apr 5, 2021): > firejail version 0.9.64.4 > no profile for git in /etc/firejail/ nor anywhere else in my home @MaelStor Odd indeed. Firejail has had a [git.profile](https://github.com/netblue30/firejail/blob/master/etc/profile-a-l/git.profile) for a while now, and it definately is in the 0.9.64.4 package on Arch. Can you confirm there is no /etc/firejail/git.profile on your system? Also, what does `which -a git` show? Try setting `quiet-by-default yes` in /etc/firejail/firejail.config temporarily to make output from a firejailed git stand out more prominently.
gitea-mirror commented 2026-05-05 09:00:26 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 5, 2021):

$ which -a git
/bin/git
/usr/bin/git

Sorry, yes indeed there is a profile for git

$ ls -la /etc/firejail | grep git
-rw-r--r--   1 root root  1390 Feb 10 20:44 com.github.bleakgrey.tootle.profile
-rw-r--r--   1 root root  1460 Feb 10 20:44 com.github.dahenson.agenda.profile
-rw-r--r--   1 root root  1578 Feb 10 20:44 com.github.johnfactotum.Foliate.profile
-rw-r--r--   1 root root   201 Feb 10 20:44 com.gitlab.newsflash.profile
-rw-r--r--   1 root root  2383 Feb 10 20:44 git-cola.profile
-rw-r--r--   1 root root  1366 Feb 10 20:44 gitg.profile
-rw-r--r--   1 root root  1195 Feb 10 20:44 github-desktop.profile
-rw-r--r--   1 root root  1185 Feb 10 20:44 git.profile
-rw-r--r--   1 root root   907 Feb 10 20:44 gitter.profile

Seems I mixed things up with firecfg --list what doesn't show git and there is no link in /usr/local/bin as shown above, so it shouldn't be active or am I wrong?

I tried running the same git commands in bash instead of zsh with another prompt etc and added a variable quiet as long as my zsh PS1 (~7000 bytes) to the environment with export SOMEVAR=$(python -c 'print("A"*7000)') with exactly the same result.

Setting quiet-by-default had no effect:

$ git pull
Error: too long environment variables, please use --rmenv
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
<!-- gh-comment-id:813140453 --> @ghost commented on GitHub (Apr 5, 2021): ``` $ which -a git /bin/git /usr/bin/git ``` Sorry, yes indeed there is a profile for git ``` $ ls -la /etc/firejail | grep git -rw-r--r-- 1 root root 1390 Feb 10 20:44 com.github.bleakgrey.tootle.profile -rw-r--r-- 1 root root 1460 Feb 10 20:44 com.github.dahenson.agenda.profile -rw-r--r-- 1 root root 1578 Feb 10 20:44 com.github.johnfactotum.Foliate.profile -rw-r--r-- 1 root root 201 Feb 10 20:44 com.gitlab.newsflash.profile -rw-r--r-- 1 root root 2383 Feb 10 20:44 git-cola.profile -rw-r--r-- 1 root root 1366 Feb 10 20:44 gitg.profile -rw-r--r-- 1 root root 1195 Feb 10 20:44 github-desktop.profile -rw-r--r-- 1 root root 1185 Feb 10 20:44 git.profile -rw-r--r-- 1 root root 907 Feb 10 20:44 gitter.profile ``` Seems I mixed things up with `firecfg --list` what doesn't show git and there is no link in `/usr/local/bin` as shown above, so it shouldn't be active or am I wrong? I tried running the same `git` commands in bash instead of zsh with another prompt etc and added a variable quiet as long as my zsh PS1 (~7000 bytes) to the environment with `export SOMEVAR=$(python -c 'print("A"*7000)')` with exactly the same result. Setting `quiet-by-default` had no effect: ``` $ git pull Error: too long environment variables, please use --rmenv fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ```
gitea-mirror commented 2026-05-05 09:00:27 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Apr 5, 2021):

It's ssh which is called by git pull.

<!-- gh-comment-id:813248032 --> @rusty-snake commented on GitHub (Apr 5, 2021): It's `ssh` which is called by `git pull`.
gitea-mirror commented 2026-05-05 09:00:28 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 5, 2021):

@glitsj16 @rusty-snake Thanks. Now it makes sense. However putting rmenv into a local profile for ssh

$ cat $HOME/.config/firejail/ssh.local
rmenv PS1
rmenv _OLD_VIRTUAL_PS1

didnt' help. I still cannot run git commands if ssh is involved because I cannot pass the --rmenv flag to firejail /usr/bin/ssh. I would love to keep ssh sandboxed but I don't see how to get rid of the error other than removing the /usr/local/bin/ssh link. What actually was the only option I've found that helped. Do you know any other possibilities?

In addition I always have to run firejail with firejail --rmenv=PS1 --rmenv=_OLD_VIRTUAL_PS1 no matter which subcommand (--list, --tree etc.) follows. Is there a way to remove environment variables in the top level like the /etc/firejail/firejail.config? I'm currently doing it with an alias but an option would be great.

IMHO It would help if I would be noticed about running ssh in a sandbox when I execute git, like it happens when running a program directly with firejail not in quiet mode. Also in the debug output of firejail --debug /usr/bin/git pull there is no indication that ssh profiles are loaded.

<!-- gh-comment-id:813483578 --> @ghost commented on GitHub (Apr 5, 2021): @glitsj16 @rusty-snake Thanks. Now it makes sense. However putting rmenv into a local profile for ssh ``` $ cat $HOME/.config/firejail/ssh.local rmenv PS1 rmenv _OLD_VIRTUAL_PS1 ``` didnt' help. I still cannot run git commands if ssh is involved because I cannot pass the `--rmenv` flag to `firejail /usr/bin/ssh`. I would love to keep ssh sandboxed but I don't see how to get rid of the error other than removing the `/usr/local/bin/ssh` link. What actually was the only option I've found that helped. Do you know any other possibilities? In addition I always have to run `firejail` with `firejail --rmenv=PS1 --rmenv=_OLD_VIRTUAL_PS1` no matter which subcommand (`--list`, `--tree` etc.) follows. Is there a way to remove environment variables in the top level like the `/etc/firejail/firejail.config`? I'm currently doing it with an alias but an option would be great. IMHO It would help if I would be noticed about running ssh in a sandbox when I execute git, like it happens when running a program directly with firejail not in quiet mode. Also in the debug output of `firejail --debug /usr/bin/git pull` there is no indication that ssh profiles are loaded.
gitea-mirror commented 2026-05-05 09:00:28 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Apr 5, 2021):

I would be noticed about running ssh in a sandbox when I execute git

Use firemon (e.g. sudo firemon)

Also in the debug output of firejail --debug /usr/bin/git pull there is no indication that ssh profiles are loaded.

There is no ssh.profile loaded if you firejail git.

<!-- gh-comment-id:813495572 --> @rusty-snake commented on GitHub (Apr 5, 2021): > I would be noticed about running ssh in a sandbox when I execute git Use firemon (e.g. `sudo firemon`) > Also in the debug output of firejail --debug /usr/bin/git pull there is no indication that ssh profiles are loaded. There is no ssh.profile loaded if you firejail git.
gitea-mirror commented 2026-05-05 09:00:29 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 5, 2021):

Using firemon in my usual environment didn't work. I guess firejail fails because of too long environment variables at an early stage and therefore nothing is recorded. And it doesn't solve the problem to get ssh working when it is invoked by git and I've got long environment variables.

However if I switch to bash with a shorter PS1 I've got firemon working and it shows me that ssh is invoked. It's not so obvious like the firejail messages about loaded profiles when starting a program with firejail $program but I guess I get my stuff working with firemon, which is great by the way.

<!-- gh-comment-id:813598748 --> @ghost commented on GitHub (Apr 5, 2021): Using `firemon` in my usual environment didn't work. I guess firejail fails because of too long environment variables at an early stage and therefore nothing is recorded. And it doesn't solve the problem to get `ssh` working when it is invoked by `git` and I've got long environment variables. However if I switch to bash with a shorter PS1 I've got `firemon` working and it shows me that `ssh` is invoked. It's not so obvious like the firejail messages about loaded profiles when starting a program with `firejail $program` but I guess I get my stuff working with `firemon`, which is great by the way.
gitea-mirror commented 2026-05-05 09:00:30 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Apr 5, 2021):

PS1 and _OLD_VIRTUAL_PS1 are the only envvar which are too long on your system. Why do you export them?

<!-- gh-comment-id:813610741 --> @rusty-snake commented on GitHub (Apr 5, 2021): `PS1` and `_OLD_VIRTUAL_PS1` are the only envvar which are too long on your system. Why do you export them?
gitea-mirror commented 2026-05-05 09:00:30 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 5, 2021):

Yes these are the only ones. It's not me who's exporting them, at least in zsh. I've tried unsetting themwith export PS1= in my .zshrc at the very end but they are still in my environment.

EDIT: Got it working. I've overseen a command at the end of the file
UPDATE: Removing the PS1 from the environment works only as long as I'm not entering a git repository. After that the PS1 and _OLD_VIRTUAL_PS1 variables pop up again in my environment.

<!-- gh-comment-id:813671038 --> @ghost commented on GitHub (Apr 5, 2021): Yes these are the only ones. It's not me who's exporting them, at least in zsh. I've tried unsetting themwith `export PS1=` in my .zshrc at the very end but they are still in my environment. EDIT: Got it working. I've overseen a command at the end of the file UPDATE: Removing the PS1 from the environment works only as long as I'm not entering a git repository. After that the PS1 and _OLD_VIRTUAL_PS1 variables pop up again in my environment.
gitea-mirror commented 2026-05-05 09:00:31 -06:00
Author
Owner
Copy link

@haarp commented on GitHub (Apr 6, 2021):

It would be great if I could get rid of the firejail='firejail --rmenv=LS_COLORS' alias on my system. alas, rmenv in the config doesn't work :(

<!-- gh-comment-id:813940956 --> @haarp commented on GitHub (Apr 6, 2021): It would be great if I could get rid of the `firejail='firejail --rmenv=LS_COLORS'` alias on my system. alas, `rmenv` in the config doesn't work :(
gitea-mirror commented 2026-05-05 09:00:31 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 6, 2021):

@haarp Have you tried a bash alias yet as suggested in #3325?

<!-- gh-comment-id:813972150 --> @ghost commented on GitHub (Apr 6, 2021): @haarp Have you tried a bash alias yet as suggested in #3325?
gitea-mirror commented 2026-05-05 09:00:31 -06:00
Author
Owner
Copy link

@haarp commented on GitHub (Apr 6, 2021):

Any alias is just a workaround tho. A real fix would either allow rmenv in the config, or simply not choke on long env variables ;)

<!-- gh-comment-id:813975406 --> @haarp commented on GitHub (Apr 6, 2021): Any alias is just a workaround tho. A real fix would either allow rmenv in the config, or simply not choke on long env variables ;)
gitea-mirror commented 2026-05-05 09:00:32 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 6, 2021):

Any alias is just a workaround tho. A real fix would either allow rmenv in the config, or simply not choke on long env variables ;)

We accept PR's. Feel free to provide one that offers at least the same level of protection against stack smashing attacks as currently implemented. You can always drop LS_COLORS if security > shiny setups.

<!-- gh-comment-id:813983248 --> @ghost commented on GitHub (Apr 6, 2021): > Any alias is just a workaround tho. A real fix would either allow rmenv in the config, or simply not choke on long env variables ;) We accept PR's. Feel free to provide one that offers at least the same level of protection against stack smashing attacks as currently implemented. You can always drop LS_COLORS if security > shiny setups.
gitea-mirror commented 2026-05-05 09:00:32 -06:00
Author
Owner
Copy link

@haarp commented on GitHub (Apr 6, 2021):

Wait, this is intentional? My impression was it was just a bug. Tho I admit it makes sense to bail out before config parsing begins.

In that case, the bail-out message could probably clarify that only --rmenv works, not rmenv in the config, so smartasses like me don't attempt it ;)

btw, it's just not shiny. I have other long env variables for varaious reasons, that my alias needs to exclude.

<!-- gh-comment-id:813987429 --> @haarp commented on GitHub (Apr 6, 2021): Wait, this is intentional? My impression was it was just a bug. Tho I admit it makes sense to bail out before config parsing begins. In that case, the bail-out message could probably clarify that only `--rmenv` works, not `rmenv` in the config, so smartasses like me don't attempt it ;) btw, it's just not shiny. I have other long env variables for varaious reasons, that my alias needs to exclude.
gitea-mirror commented 2026-05-05 09:00:33 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Apr 6, 2021):

How about using an extra environment.global file in /etc/firejail which blacklists environment varaibles, so I would have more control over the environment at an early stage. A simple list of environment variables one per line would be enough for me but perhaps you see better possibilities.

<!-- gh-comment-id:814394490 --> @ghost commented on GitHub (Apr 6, 2021): How about using an extra environment.global file in `/etc/firejail` which blacklists environment varaibles, so I would have more control over the environment at an early stage. A simple list of environment variables one per line would be enough for me but perhaps you see better possibilities.
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#2314
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?