github-starred/firejail

Fork 0

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

[GH-ISSUE #3851] Compiled-in environment/arg limits causing issues #2422

New issue

Closed

opened 2026-05-05 09:05:53 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 09:05:53 -06:00

Owner

Originally created by @hlein on GitHub (Dec 28, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3851

Bug and expected behavior
88258569cb added some reasonable-looking limits on environment (number and size of environment variables) and arguments (number, maybe also size?).

Except... this causes some regressions with things that used to work fine.

It would be great if these limits could be specified in firejail config files rather than compiled in, so that I could then arrange for .local overrides where needed. Or failing that, activated by an on-by-default flag like --envcheck, which could be suppressed with --ignore-envcheck.

Examples:

On gentoo, during package building, some keywords and targets get expanded into quite-large environment variables. For instance the build system keeps track of which Python versions you have installed, and which targets / USE flags (optional compile-time features) you have enabled; some package-flag / dependency calculations then explode if you have say python-2.7, python-3.6, python-3.7, and python-3.8 all installed at once. This can exceed the current hardcoded limits, so builds can fail at strange points (patch, strings, fontforge for some reason) if the build user's processes are being firejail'ed. If I could arrange for the build user to have higher limits, it could still benefit from firejail otherwise, and the rest of the system's firejail uses could benefit from the reasonable lower defaults.

I also have some file-syncing scripts / Makefiles that bundle up different file sets and rsync them by explicit argument list (rsync a b c d e f g h i j ... targethost:). I could modify these to pipe a list to rsync and do --files=from=-, but it would be simpler to just increase the ceilings in an rsync.local and ssh.local, and/or pass a --ignore-envcheck to firejail in those cases.

Originally created by @hlein on GitHub (Dec 28, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3851 **Bug and expected behavior** https://github.com/netblue30/firejail/commit/88258569cb5f455dd39447867e559bfba20d91c7 added some reasonable-looking limits on environment (number and size of environment variables) and arguments (number, maybe also size?). Except... this causes some regressions with things that used to work fine. It would be great if these limits could be specified in firejail config files rather than compiled in, so that I could then arrange for .local overrides where needed. Or failing that, activated by an on-by-default flag like `--envcheck`, which could be suppressed with `--ignore-envcheck`. Examples: On gentoo, during package building, some keywords and targets get expanded into quite-large environment variables. For instance the build system keeps track of which Python versions you have installed, and which targets / USE flags (optional compile-time features) you have enabled; some package-flag / dependency calculations then explode if you have say python-2.7, python-3.6, python-3.7, and python-3.8 all installed at once. This can exceed the current hardcoded limits, so builds can fail at strange points (patch, strings, fontforge for some reason) if the build user's processes are being firejail'ed. If I could arrange for the build user to have higher limits, it could still benefit from firejail otherwise, and the rest of the system's firejail uses could benefit from the reasonable lower defaults. I also have some file-syncing scripts / Makefiles that bundle up different file sets and rsync them by explicit argument list (`rsync a b c d e f g h i j ... targethost:`). I could modify these to pipe a list to rsync and do `--files=from=-`, but it would be simpler to just increase the ceilings in an `rsync.local` and `ssh.local`, and/or pass a `--ignore-envcheck` to firejail in those cases.

gitea-mirror

2026-05-05 09:05:53 -06:00

closed this issue
added the
duplicate
label

gitea-mirror commented

2026-05-05 09:05:56 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Dec 28, 2020):

Yep.
I've had these patched out in my personal builds forever.

@SkewedZeppelin commented on GitHub (Dec 28, 2020): Yep. I've had these patched out in my personal builds forever.

gitea-mirror commented

2026-05-05 09:05:57 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 8, 2021):

Fixed by #3322?

@rusty-snake commented on GitHub (Mar 8, 2021): Fixed by #3322?

gitea-mirror commented

2026-05-05 09:05:57 -06:00

Author

Owner

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

Duplicate of #3678?

@rusty-snake commented on GitHub (Apr 6, 2021): Duplicate of #3678?

gitea-mirror commented

2026-05-05 09:05:58 -06:00

Author

Owner

@hlein commented on GitHub (May 16, 2021):

Fixed by #3322?

Nope. Using b5a4035912, which should include 1c7ea15b30 from #3322:

In the "rsync a ridiculously long list of filenames" test, I get:

Error: too many arguments

Similar thing when emerging a package on Gentoo when patch has been firejail'ed:

Error: too many environment variables

(Different part of the same overall set of changes.)

@hlein commented on GitHub (May 16, 2021): > Fixed by #3322? Nope. Using b5a40359125db3a2df9a6f6e9c12c476dd9b150b, which should include 1c7ea15b30d49d32a0e3cb79152514f1aeb19397 from #3322: In the "rsync a ridiculously long list of filenames" test, I get: `Error: too many arguments` Similar thing when emerging a package on Gentoo when `patch` has been firejail'ed: `Error: too many environment variables` (Different part of the same overall set of changes.)

gitea-mirror commented

2026-05-05 09:05:58 -06:00

Author

Owner

@hlein commented on GitHub (May 16, 2021):

Duplicate of #3678?

Hm, related but I don't think a dupe. #3678 seems to be strictly about "a single env var that exceeds a length limit", but in this case the number of arguments, the number of env vars, and the env var lengths cause problems.

@hlein commented on GitHub (May 16, 2021): > Duplicate of #3678? Hm, related but I don't think a dupe. #3678 seems to be strictly about "a single env var that exceeds a length limit", but in this case the number of arguments, the number of env vars, and the env var lengths cause problems.

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Oct 22, 2025):

Duplicate of #3678?

Hm, related but I don't think a dupe.
#3678 seems to be
strictly about "a single env var that exceeds a length limit", but in this
case the number of arguments, the number of env vars, and the env var lengths
cause problems.

Closing as a duplicate of:

#3678
#4633

As making the count/length configurable for both arguments and environment
variables should also resolve this issue.

If that is not the case, please clarify.

@kmk3 commented on GitHub (Oct 22, 2025): > > Duplicate of [#3678](https://github.com/netblue30/firejail/issues/3678)? > > Hm, related but I don't think a dupe. > [#3678](https://github.com/netblue30/firejail/issues/3678) seems to be > strictly about "a single env var that exceeds a length limit", but in this > case the number of arguments, the number of env vars, and the env var lengths > cause problems. Closing as a duplicate of: * #3678 * #4633 As making the count/length configurable for both arguments and environment variables should also resolve this issue. If that is not the case, please clarify.

gitea-mirror referenced this issue

2026-05-05 10:17:29 -06:00

[PR #2422] [MERGED] Create nano.profile #4297

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

No description provided.

Rows
Columns