[GH-ISSUE #4633] Higher argument limits? (Error: too many arguments)

gitea-mirror commented

2026-05-05 09:23:47 -06:00

Owner

Originally created by @Artefact2 on GitHub (Oct 23, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4633

It seems that firejail has much lower limits for the number of arguments it supports (or the total size of argv), compared to other standard programs. This makes using firejail with long file lists a painful process, as standard tools like find -exec or xargs won't work out of the box.

Here's a simple way to reproduce:

% touch $(seq 1000 2000)
% /usr/bin/echo ./*
(works)
% firejail --noprofile /usr/bin/echo ./*
Error: too many arguments
% ls --zero | xargs -0 /usr/bin/echo
(works)
% ls --zero | xargs -0 firejail --noprofile /usr/bin/echo
Error: too many arguments
% find . -exec /usr/bin/echo {} +
(works)
% find . -exec firejail --noprofile /usr/bin/echo {} +
Error: too many arguments

For additionnal reference:

% echo $SHELL
/bin/zsh
% firejail --version
firejail version 0.9.66
% xargs --show-limits
Your environment variables take up 1198 bytes
POSIX upper limit on argument length (this system): 2502482
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 2501284
Size of command buffer we are actually using: 131072
Maximum parallelism (--max-procs must be no greater): 2147483647

Relates to:

Originally created by @Artefact2 on GitHub (Oct 23, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4633 It seems that firejail has much lower limits for the number of arguments it supports (or the total size of argv), compared to other standard programs. This makes using firejail with long file lists a painful process, as standard tools like `find -exec` or `xargs` won't work out of the box. Here's a simple way to reproduce: ~~~ % touch $(seq 1000 2000) % /usr/bin/echo ./* (works) % firejail --noprofile /usr/bin/echo ./* Error: too many arguments % ls --zero | xargs -0 /usr/bin/echo (works) % ls --zero | xargs -0 firejail --noprofile /usr/bin/echo Error: too many arguments % find . -exec /usr/bin/echo {} + (works) % find . -exec firejail --noprofile /usr/bin/echo {} + Error: too many arguments ~~~ For additionnal reference: ~~~ % echo $SHELL /bin/zsh % firejail --version firejail version 0.9.66 % xargs --show-limits Your environment variables take up 1198 bytes POSIX upper limit on argument length (this system): 2502482 POSIX smallest allowable upper limit on argument length (all systems): 4096 Maximum length of command we could actually use: 2501284 Size of command buffer we are actually using: 131072 Maximum parallelism (--max-procs must be no greater): 2147483647 ~~~ Relates to: * #3350 * #3386 * #3678 * #3851

gitea-mirror

2026-05-05 09:23:47 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 09:23:50 -06:00

Author

Owner

@kmk3 commented on GitHub (Oct 23, 2021):

@Artefact2 commented on Oct 23:

It seems that firejail has much lower limits for the number of arguments it
supports (or the total size of argv), compared to other standard programs.
This makes using firejail with long file lists a painful process, as standard
tools like find -exec or xargs won't work out of the box.

Here's a simple way to reproduce:

% touch $(seq 1000 2000)
% /usr/bin/echo ./*
(works)
% firejail --noprofile /usr/bin/echo ./*
Error: too many arguments
% ls --zero | xargs -0 /usr/bin/echo
(works)
% ls --zero | xargs -0 firejail --noprofile /usr/bin/echo
Error: too many arguments
% find . -exec /usr/bin/echo {} +
(works)
% find . -exec firejail --noprofile /usr/bin/echo {} +
Error: too many arguments

For additionnal reference:

% echo $SHELL
/bin/zsh
% firejail --version
firejail version 0.9.66
% xargs --show-limits
Your environment variables take up 1198 bytes
POSIX upper limit on argument length (this system): 2502482
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 2501284
Size of command buffer we are actually using: 131072
Maximum parallelism (--max-procs must be no greater): 2147483647

Current limit:

#define MAX_ARGS 128		// maximum number of command arguments (argc)
#define MAX_ARG_LEN (PATH_MAX + 32) // --foobar=PATH
extern char *fullargv[MAX_ARGS];
extern int fullargc;

That's been the case from the beginning it seems:

https://github.com/netblue30/firejail/blob/1379851360349d6617ad32944a25ee5e2bb74fc2/src/firejail/firejail.h#L151-L153

Main usage:

			int j;
			for (i = 1, j = fullargc; i < argc && j < MAX_ARGS; i++, j++, fullargc++)
				fullargv[j] = argv[i];

			// replace argc/argv with fullargc/fullargv
			argv = fullargv;
			argc = j;

@netblue30 Is there any specific reason for this limit?

It seems that something like the following could be done instead:

fullargv = malloc(strlen(argv) + 1);

Anyway, I'm currently already working on 2 other things, so if anyone wants to
take it, feel free to do so.

@kmk3 commented on GitHub (Oct 23, 2021): @Artefact2 commented [on Oct 23](https://github.com/netblue30/firejail/issues/4633#issue-1034142792): > It seems that firejail has much lower limits for the number of arguments it > supports (or the total size of argv), compared to other standard programs. > This makes using firejail with long file lists a painful process, as standard > tools like `find -exec` or `xargs` won't work out of the box. > > Here's a simple way to reproduce: > > ``` > % touch $(seq 1000 2000) > % /usr/bin/echo ./* > (works) > % firejail --noprofile /usr/bin/echo ./* > Error: too many arguments > % ls --zero | xargs -0 /usr/bin/echo > (works) > % ls --zero | xargs -0 firejail --noprofile /usr/bin/echo > Error: too many arguments > % find . -exec /usr/bin/echo {} + > (works) > % find . -exec firejail --noprofile /usr/bin/echo {} + > Error: too many arguments > ``` > > For additionnal reference: > > ``` > % echo $SHELL > /bin/zsh > % firejail --version > firejail version 0.9.66 > % xargs --show-limits > Your environment variables take up 1198 bytes > POSIX upper limit on argument length (this system): 2502482 > POSIX smallest allowable upper limit on argument length (all systems): 4096 > Maximum length of command we could actually use: 2501284 > Size of command buffer we are actually using: 131072 > Maximum parallelism (--max-procs must be no greater): 2147483647 > ``` [Current limit][1]: > ```C > #define MAX_ARGS 128 // maximum number of command arguments (argc) > #define MAX_ARG_LEN (PATH_MAX + 32) // --foobar=PATH > extern char *fullargv[MAX_ARGS]; > extern int fullargc; > ``` That's been the case from the beginning it seems: * <https://github.com/netblue30/firejail/blob/1379851360349d6617ad32944a25ee5e2bb74fc2/src/firejail/firejail.h#L151-L153> [Main usage][2]: ```c int j; for (i = 1, j = fullargc; i < argc && j < MAX_ARGS; i++, j++, fullargc++) fullargv[j] = argv[i]; // replace argc/argv with fullargc/fullargv argv = fullargv; argc = j; ``` @netblue30 Is there any specific reason for this limit? It seems that something like the following could be done instead: ```c fullargv = malloc(strlen(argv) + 1); ``` Anyway, I'm currently already working on 2 other things, so if anyone wants to take it, feel free to do so. [1]: https://github.com/netblue30/firejail/blob/7f0b5ddd8881c5276138b061109ab48eb5165201/src/firejail/firejail.h#L372-L375 [2]: https://github.com/netblue30/firejail/blob/d9403dcdc8cfb23d5350b0488817a5eaa5a0f20d/src/firejail/main.c#L1185-L1191

gitea-mirror commented

2026-05-05 09:23:51 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 23, 2021):

Even if you would use malloc:

efbf74e124/src/firejail/main.c (L1005-L1008)

@rusty-snake commented on GitHub (Oct 23, 2021): Even if you would use malloc: https://github.com/netblue30/firejail/blob/efbf74e12421c97d8a1756649422f83f4a0b7e50/src/firejail/main.c#L1005-L1008

gitea-mirror commented

2026-05-05 09:23:52 -06:00

Author

Owner

@kmk3 commented on GitHub (Oct 23, 2021):

@rusty-snake commented on Oct 23:

Even if you would use malloc:

efbf74e124/src/firejail/main.c (L1005-L1008)

MAX_ARGS can be replaced with ARG_MAX.

Relates to #4583.

@kmk3 commented on GitHub (Oct 23, 2021): @rusty-snake commented [on Oct 23](https://github.com/netblue30/firejail/issues/4633#issuecomment-950185661): > Even if you would use malloc: > > https://github.com/netblue30/firejail/blob/efbf74e12421c97d8a1756649422f83f4a0b7e50/src/firejail/main.c#L1005-L1008 `MAX_ARGS` can be replaced with `ARG_MAX`. Relates to #4583.

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Oct 23, 2021):

On second thought, I don't know why a limit on argc would be needed (there is
none defined by POSIX at least); I think it would only matter on argv, because
of e.g.: memory usage.

@kmk3 commented on GitHub (Oct 23, 2021): On second thought, I don't know why a limit on argc would be needed (there is none defined by POSIX at least); I think it would only matter on argv, because of e.g.: memory usage.

gitea-mirror commented

2026-05-05 09:23:54 -06:00

Author

Owner

@topimiettinen commented on GitHub (Oct 23, 2021):

On second thought, I don't know why a limit on argc would be needed (there is none defined by POSIX at least); I think it would only matter on argv, because of e.g.: memory usage.

It's a security feature: argv (and environment) could be used to fill the stack area so that stack smashing would be easier. Similar check exists for environment variables too. Raising the limit to ARG_MAX (524288) wouldn't be a good idea, but 128 could be raised a bit higher.

In general, portability to POSIX isn't very interesting for Firejail, since it depends on Linux-only features like mount namespaces, seccomp and capabilities. Without them Firejail would be useless. I don't think BSDs have anything comparable.

@topimiettinen commented on GitHub (Oct 23, 2021): > On second thought, I don't know why a limit on argc would be needed (there is none defined by POSIX at least); I think it would only matter on argv, because of e.g.: memory usage. It's a security feature: argv (and environment) could be used to fill the stack area so that stack smashing would be easier. Similar check exists for environment variables too. Raising the limit to ARG_MAX (524288) wouldn't be a good idea, but 128 could be raised a bit higher. In general, portability to POSIX isn't very interesting for Firejail, since it depends on Linux-only features like mount namespaces, seccomp and capabilities. Without them Firejail would be useless. I don't think BSDs have anything comparable.

gitea-mirror commented

2026-05-05 09:23:55 -06:00

Author

Owner

@kmk3 commented on GitHub (Oct 23, 2021):

topimiettinen commented on Oct 23:

On second thought, I don't know why a limit on argc would be needed (there
is none defined by POSIX at least); I think it would only matter on argv,
because of e.g.: memory usage.

It's a security feature: argv (and environment) could be used to fill the
stack area so that stack smashing would be easier. Similar check exists for
environment variables too. Raising the limit to ARG_MAX (524288) wouldn't be
a good idea, but 128 could be raised a bit higher.

I see, that makes sense. But still, wouldn't it make more sense to check only
for argv (regardless of the specific upper bound number that would be chosen)
rather than argc?

In general, portability to POSIX isn't very interesting for Firejail, since
it depends on Linux-only features like mount namespaces, seccomp and
capabilities. Without them Firejail would be useless. I don't think BSDs have
anything comparable.

Off-topic discussion

Never thought I'd get an appropriate occasion to do it, but:

I'd just like to interject for a moment. What you're referring to as Linux, is
in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux.
Linux is not an operating system unto itself, but rather another free component
of a fully functioning GNU system made useful by the GNU corelibs, shell
utilities and vital system components comprising a full OS as defined by POSIX.

The examples listed are kernel-level features, but limits.h is system-defined
and thus can be overridden by e.g.: other OS components. #4583 is a great
example of that, as glibc overrides what Linux defines in limits.h, but musl
doesn't. So keeping POSIX in mind in this case could help with libc
portability (rather than kernel portability). There is also #4293, which was
intended to make the configure script portable between different
POSIX-compliant shells (e.g.: bash and dash).

Anyway, POSIX was just an example in my previous comment; it's the only thing
that I know that explicitly defines such limits. What I meant is that
Linux/glibc/musl define related limits using the macro names specified by
POSIX, but neither Linux/glibc/musl nor POSIX define any limits for argc AFAIK.

@kmk3 commented on GitHub (Oct 23, 2021): topimiettinen commented [on Oct 23](https://github.com/netblue30/firejail/issues/4633#issuecomment-950194984): > > On second thought, I don't know why a limit on argc would be needed (there > > is none defined by POSIX at least); I think it would only matter on argv, > > because of e.g.: memory usage. > > It's a security feature: argv (and environment) could be used to fill the > stack area so that stack smashing would be easier. Similar check exists for > environment variables too. Raising the limit to ARG_MAX (524288) wouldn't be > a good idea, but 128 could be raised a bit higher. I see, that makes sense. But still, wouldn't it make more sense to check only for argv (regardless of the specific upper bound number that would be chosen) rather than argc? > In general, portability to POSIX isn't very interesting for Firejail, since > it depends on Linux-only features like mount namespaces, seccomp and > capabilities. Without them Firejail would be useless. I don't think BSDs have > anything comparable. <details> <summary>Off-topic discussion</summary> Never thought I'd get an appropriate occasion to do it, but: I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. </details> The examples listed are kernel-level features, but limits.h is system-defined and thus can be overridden by e.g.: other OS components. #4583 is a great example of that, as glibc overrides what Linux defines in limits.h, but musl doesn't. So keeping POSIX in mind in this case could help with libc portability (rather than kernel portability). There is also #4293, which was intended to make the configure script portable between different POSIX-compliant shells (e.g.: bash and dash). Anyway, POSIX was just an example in my previous comment; it's the only thing that I know that explicitly defines such limits. What I meant is that Linux/glibc/musl define related limits using the macro names specified by POSIX, but neither Linux/glibc/musl nor POSIX define any limits for argc AFAIK.

gitea-mirror commented

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

Author

Owner

@topimiettinen commented on GitHub (Oct 23, 2021):

topimiettinen commented on Oct 23:

On second thought, I don't know why a limit on argc would be needed (there
is none defined by POSIX at least); I think it would only matter on argv,
because of e.g.: memory usage.

It's a security feature: argv (and environment) could be used to fill the
stack area so that stack smashing would be easier. Similar check exists for
environment variables too. Raising the limit to ARG_MAX (524288) wouldn't be
a good idea, but 128 could be raised a bit higher.

I see, that makes sense. But still, wouldn't it make more sense to check only for argv (regardless of the specific upper bound number that would be chosen) rather than argc?

The important thing is actually the size, or the sum of all arguments.

In general, portability to POSIX isn't very interesting for Firejail, since
it depends on Linux-only features like mount namespaces, seccomp and
capabilities. Without them Firejail would be useless. I don't think BSDs have
anything comparable.

Off-topic discussion

Never thought I'd get an appropriate occasion to do it, but:

I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

I think calling a system GNU is exaggerating, there are many other non-GNU components in the system too and the distros also put a lot of effort to integration. The most important piece these days is the browser, which isn't GNU and a lot of old UNIX-like GNU or POSIX stuff with text UIs isn't very cool anymore. It isn't fair calling the phone systems 'Android' either, but calling it 'Linux/Bionic' would be silly.

The examples listed are kernel-level features, but limits.h is system-defined and thus can be overridden by e.g.: other OS components. #4583 is a great example of that, as glibc overrides what Linux defines in limits.h, but musl doesn't. So keeping POSIX in mind in this case could help with libc portability (rather than kernel portability). There is also #4293, which was intended to make the configure script portable between different POSIX-compliant shells (e.g.: bash and dash).

Anyway, POSIX was just an example in my previous comment; it's the only thing that I know that explicitly defines such limits. What I meant is that Linux/glibc/musl define related limits using the macro names specified by POSIX, but neither Linux/glibc/musl nor POSIX define any limits for argc AFAIK.

Good points with portability to musl. Though does any distro use it for real?

@topimiettinen commented on GitHub (Oct 23, 2021): > topimiettinen commented [on Oct 23](https://github.com/netblue30/firejail/issues/4633#issuecomment-950194984): > > > > On second thought, I don't know why a limit on argc would be needed (there > > > is none defined by POSIX at least); I think it would only matter on argv, > > > because of e.g.: memory usage. > > > > > > It's a security feature: argv (and environment) could be used to fill the > > stack area so that stack smashing would be easier. Similar check exists for > > environment variables too. Raising the limit to ARG_MAX (524288) wouldn't be > > a good idea, but 128 could be raised a bit higher. > > I see, that makes sense. But still, wouldn't it make more sense to check only for argv (regardless of the specific upper bound number that would be chosen) rather than argc? The important thing is actually the size, or the sum of all arguments. > > In general, portability to POSIX isn't very interesting for Firejail, since > > it depends on Linux-only features like mount namespaces, seccomp and > > capabilities. Without them Firejail would be useless. I don't think BSDs have > > anything comparable. <details> <summary>Off-topic discussion</summary> > Never thought I'd get an appropriate occasion to do it, but: > > I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. I think calling a system GNU is exaggerating, there are many other non-GNU components in the system too and the distros also put a lot of effort to integration. The most important piece these days is the browser, which isn't GNU and a lot of old UNIX-like GNU or POSIX stuff with text UIs isn't very cool anymore. It isn't fair calling the phone systems 'Android' either, but calling it 'Linux/Bionic' would be silly. </details> > The examples listed are kernel-level features, but limits.h is system-defined and thus can be overridden by e.g.: other OS components. #4583 is a great example of that, as glibc overrides what Linux defines in limits.h, but musl doesn't. So keeping POSIX in mind in this case could help with libc portability (rather than kernel portability). There is also #4293, which was intended to make the configure script portable between different POSIX-compliant shells (e.g.: bash and dash). > > Anyway, POSIX was just an example in my previous comment; it's the only thing that I know that explicitly defines such limits. What I meant is that Linux/glibc/musl define related limits using the macro names specified by POSIX, but neither Linux/glibc/musl nor POSIX define any limits for argc AFAIK. Good points with portability to musl. Though does any distro use it for real?

gitea-mirror commented

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

Author

Owner

@reinerh commented on GitHub (Oct 23, 2021):

Good points with portability to musl. Though does any distro use it for real?

Alpine comes to mind. And many embedded distributions like OpenWrt.

@reinerh commented on GitHub (Oct 23, 2021): > Good points with portability to musl. Though does any distro use it for real? Alpine comes to mind. And many embedded distributions like OpenWrt.

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Oct 24, 2021):

topimiettinen commented on Oct 23:

topimiettinen commented on Oct 23:

On second thought, I don't know why a limit on argc would be needed
(there is none defined by POSIX at least); I think it would only matter
on argv, because of e.g.: memory usage.

It's a security feature: argv (and environment) could be used to fill the
stack area so that stack smashing would be easier. Similar check exists
for environment variables too. Raising the limit to ARG_MAX (524288)
wouldn't be a good idea, but 128 could be raised a bit higher.

I see, that makes sense. But still, wouldn't it make more sense to check
only for argv (regardless of the specific upper bound number that would be
chosen) rather than argc?

The important thing is actually the size, or the sum of all arguments.

So something like this?

int i;
size_t total_argsz = argc;
for (i = 0; i < argc; i++) {
	total_argsz += strlen(argv[i]) + 1;

	if (total_argsz > SOME_ARG_MAX)
		// die
}

Off-topic discussion

In general, portability to POSIX isn't very interesting for Firejail,
since it depends on Linux-only features like mount namespaces, seccomp
and capabilities. Without them Firejail would be useless. I don't think
BSDs have anything comparable.

Never thought I'd get an appropriate occasion to do it, but:

I'd just like to interject for a moment. What you're referring to as Linux,
is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus
Linux. Linux is not an operating system unto itself, but rather another
free component of a fully functioning GNU system made useful by the GNU
corelibs, shell utilities and vital system components comprising a full OS
as defined by POSIX.

I think calling a system GNU is exaggerating, there are many other non-GNU
components in the system too and the distros also put a lot of effort to
integration. The most important piece these days is the browser, which isn't
GNU and a lot of old UNIX-like GNU or POSIX stuff with text UIs isn't very
cool anymore. It isn't fair calling the phone systems 'Android' either, but
calling it 'Linux/Bionic' would be silly.

The copypasta was posted mostly in jest to point out that there is more to the
OS than the kernel (and to POSIX than the kernel-related functions and the C
extensions). I think that the main point is to remind people that the shell,
coreutils, make and the compiler are essential parts of the OS (as in, you
couldn't even build the Linux kernel without them), which are also all
specified by POSIX. You can have a "complete" (i.e.: self-bootstrapping) Linux
software distribution (GNU or not) without a web browser, but probably not
without the aforementioned tools. That is, everything else could be considered
an application built on top of the OS, not the OS itself.

As for Android, it takes an absurd amount of disk space (in the realm of
multiple GiB with all the tooling last I checked) just to build a normal
application, let alone the entire system (it requires dozens of GiB AFAIK).
And I'm not sure that all of the necessary tools are even available under FLOSS
licenses, let alone packaged in their entirety on e.g.: Debian. And that is
just to effectively cross-compile it from another system; I doubt it's even
feasible to completely do it on a conventional Android device itself, let alone
to be able to actually boot the result. AFAICT the unix-y portions of it are
mostly buried under layers and layers of frameworks and abstractions.
System-wise it is as far from a conventional Linux or BSD software distribution
as it gets and should indeed probably just be considered its own (incomplete)
thing.

Now, something similar could be said about the complexity of gcc/clang (either
of which is currently required to build the kernel AFAIK), though there is work
being done to enable smaller (and C-based) alternatives, but even disregarding
that, I would consider gcc/clang to be at least more familiar beasts than the
Java runtimes and what not.

The examples listed are kernel-level features, but limits.h is
system-defined and thus can be overridden by e.g.: other OS components.
#4583 is a great example of that, as glibc overrides what Linux defines in
limits.h, but musl doesn't. So keeping POSIX in mind in this case could
help with libc portability (rather than kernel portability). There is also
#4293, which was intended to make the configure script portable between
different POSIX-compliant shells (e.g.: bash and dash).

Anyway, POSIX was just an example in my previous comment; it's the only
thing that I know that explicitly defines such limits. What I meant is that
Linux/glibc/musl define related limits using the macro names specified by
POSIX, but neither Linux/glibc/musl nor POSIX define any limits for argc
AFAIK.

Good points with portability to musl. Though does any distro use it for real?

Off the top of my head, from the distros that either do or did package firejail
(from README.md):

Alpine Linux (musl)
Void Linux (either glibc or musl)

Alpine is known for being small and so is often used on Docker containers.

postmarketOS is based on Alpine and is intended for phones (and so is much
closer to a conventional distro than Android).

Void is the one that officially supports the most BSD-y userland of the list
that I know of. Examples: runit, seatd, sndio.

Also, the main KISS Linux build is musl-based, but I'm not aware of any
firejail build recipe.

@kmk3 commented on GitHub (Oct 24, 2021): topimiettinen commented [on Oct 23](https://github.com/netblue30/firejail/issues/4633#issuecomment-950219867): > > topimiettinen commented [on Oct 23](https://github.com/netblue30/firejail/issues/4633#issuecomment-950194984): > > > > > > On second thought, I don't know why a limit on argc would be needed > > > > (there is none defined by POSIX at least); I think it would only matter > > > > on argv, because of e.g.: memory usage. > > > > > > It's a security feature: argv (and environment) could be used to fill the > > > stack area so that stack smashing would be easier. Similar check exists > > > for environment variables too. Raising the limit to ARG_MAX (524288) > > > wouldn't be a good idea, but 128 could be raised a bit higher. > > > > I see, that makes sense. But still, wouldn't it make more sense to check > > only for argv (regardless of the specific upper bound number that would be > > chosen) rather than argc? > > The important thing is actually the size, or the sum of all arguments. So something like this? ```C int i; size_t total_argsz = argc; for (i = 0; i < argc; i++) { total_argsz += strlen(argv[i]) + 1; if (total_argsz > SOME_ARG_MAX) // die } ``` <details> <summary>Off-topic discussion</summary> > > > In general, portability to POSIX isn't very interesting for Firejail, > > > since it depends on Linux-only features like mount namespaces, seccomp > > > and capabilities. Without them Firejail would be useless. I don't think > > > BSDs have anything comparable. > > > > Never thought I'd get an appropriate occasion to do it, but: > > > > I'd just like to interject for a moment. What you're referring to as Linux, > > is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus > > Linux. Linux is not an operating system unto itself, but rather another > > free component of a fully functioning GNU system made useful by the GNU > > corelibs, shell utilities and vital system components comprising a full OS > > as defined by POSIX. > > I think calling a system GNU is exaggerating, there are many other non-GNU > components in the system too and the distros also put a lot of effort to > integration. The most important piece these days is the browser, which isn't > GNU and a lot of old UNIX-like GNU or POSIX stuff with text UIs isn't very > cool anymore. It isn't fair calling the phone systems 'Android' either, but > calling it 'Linux/Bionic' would be silly. The copypasta was posted mostly in jest to point out that there is more to the OS than the kernel (and to POSIX than the kernel-related functions and the C extensions). I think that the main point is to remind people that the shell, coreutils, make and the compiler are essential parts of the OS (as in, you couldn't even build the Linux kernel without them), which are also all specified by POSIX. You can have a "complete" (i.e.: self-bootstrapping) Linux software distribution (GNU or not) without a web browser, but probably not without the aforementioned tools. That is, everything else could be considered an application built on top of the OS, not the OS itself. As for Android, it takes an absurd amount of disk space (in the realm of multiple GiB with all the tooling last I checked) just to build a normal application, let alone the entire system (it requires dozens of GiB AFAIK). And I'm not sure that all of the necessary tools are even available under FLOSS licenses, let alone packaged in their entirety on e.g.: Debian. And that is just to effectively cross-compile it from another system; I doubt it's even feasible to completely do it on a conventional Android device itself, let alone to be able to actually boot the result. AFAICT the unix-y portions of it are mostly buried under layers and layers of frameworks and abstractions. System-wise it is as far from a conventional Linux or BSD software distribution as it gets and should indeed probably just be considered its own (incomplete) thing. Now, something similar could be said about the complexity of gcc/clang (either of which is currently required to build the kernel AFAIK), though there is work being done to enable smaller (and C-based) alternatives, but even disregarding that, I would consider gcc/clang to be at least more familiar beasts than the Java runtimes and what not. </details> > > The examples listed are kernel-level features, but limits.h is > > system-defined and thus can be overridden by e.g.: other OS components. > > #4583 is a great example of that, as glibc overrides what Linux defines in > > limits.h, but musl doesn't. So keeping POSIX in mind in this case could > > help with libc portability (rather than kernel portability). There is also > > #4293, which was intended to make the configure script portable between > > different POSIX-compliant shells (e.g.: bash and dash). > > > > Anyway, POSIX was just an example in my previous comment; it's the only > > thing that I know that explicitly defines such limits. What I meant is that > > Linux/glibc/musl define related limits using the macro names specified by > > POSIX, but neither Linux/glibc/musl nor POSIX define any limits for argc > > AFAIK. > > Good points with portability to musl. Though does any distro use it for real? Off the top of my head, from the distros that either do or did package firejail (from README.md): * Alpine Linux (musl) * Void Linux (either glibc or musl) Alpine is known for being small and so is often used on Docker containers. postmarketOS is based on Alpine and is intended for phones (and so is much closer to a conventional distro than Android). Void is the one that officially supports the most BSD-y userland of the list that I know of. Examples: runit, seatd, sndio. Also, the main KISS Linux build is musl-based, but I'm not aware of any firejail build recipe.

gitea-mirror commented

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

Author

Owner

@topimiettinen commented on GitHub (Oct 24, 2021):

topimiettinen commented on Oct 23:

topimiettinen commented on Oct 23:

On second thought, I don't know why a limit on argc would be needed
(there is none defined by POSIX at least); I think it would only matter
on argv, because of e.g.: memory usage.

It's a security feature: argv (and environment) could be used to fill the
stack area so that stack smashing would be easier. Similar check exists
for environment variables too. Raising the limit to ARG_MAX (524288)
wouldn't be a good idea, but 128 could be raised a bit higher.

I see, that makes sense. But still, wouldn't it make more sense to check
only for argv (regardless of the specific upper bound number that would be
chosen) rather than argc?

The important thing is actually the size, or the sum of all arguments.

So something like this?
int i;
size_t total_argsz = argc;
for (i = 0; i < argc; i++) {
	total_argsz += strlen(argv[i]) + 1;

	if (total_argsz > SOME_ARG_MAX)
		// die
}

Yes. The calculation could also consider environment variables. Maybe simply (knowing the layout of argv/env/auxv in stack) just check that stack isn't used too much.

Off-topic discussion

In general, portability to POSIX isn't very interesting for Firejail,
since it depends on Linux-only features like mount namespaces, seccomp
and capabilities. Without them Firejail would be useless. I don't think
BSDs have anything comparable.

Never thought I'd get an appropriate occasion to do it, but:
I'd just like to interject for a moment. What you're referring to as Linux,
is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus
Linux. Linux is not an operating system unto itself, but rather another
free component of a fully functioning GNU system made useful by the GNU
corelibs, shell utilities and vital system components comprising a full OS
as defined by POSIX.

I think calling a system GNU is exaggerating, there are many other non-GNU
components in the system too and the distros also put a lot of effort to
integration. The most important piece these days is the browser, which isn't
GNU and a lot of old UNIX-like GNU or POSIX stuff with text UIs isn't very
cool anymore. It isn't fair calling the phone systems 'Android' either, but
calling it 'Linux/Bionic' would be silly.

The copypasta was posted mostly in jest to point out that there is more to POSIX than the kernel-related functions and the C extensions. I think that the main point is to remind people that the shell, coreutils, make and the compiler are essential parts of the OS (as in, you couldn't even build the Linux kernel without them), which are also all specified by POSIX. You can have a "complete" (i.e.: self-bootstrapping) Linux software distribution (GNU or not) without a web browser, but probably not without the aforementioned tools. That is, everything else could be considered an application built on top of the OS, not the OS itself.

We're approaching the point where shell and other utils aren't used very much for lauching apps in for the typical installation: kernel -> systemd -> sddm -> 'systemd --user' -> app (browser etc.). Also the development is done more and more in the cloud, like this GitHub. With vscode.dev it's probably possible to do all development, including editing, remotely.

With Meson build system, a shell isn't necessary when compiling and it's much saner (and faster) than Make. Perhaps Firejail should switch to Meson at some point.

I've actually long wanted a system, which would have two operating modes:

production, max security mode: root user not allowed, minimal software: no dev tools, shells, compilers, coreutils; as much as possible strictly read-only (squashfs), full net access
development / system administration mode where system can be updated, configuration can be edited and the production mode image can be generated, but only limited (only distro package repos) or no net access

Requiring a reboot to switch modes or even switch Secure Boot on/off from UEFI BIOS could be OK. Maybe the production image could be even produced by a CI job far away.

As for Android, it takes an absurd amount of disk space (in the realm of multiple GiB with all the tooling last I checked) just to build a normal application, let alone the entire system (it requires dozens of GiB AFAIK). And I'm not sure that all of the necessary tools are even available under FLOSS licenses, let alone packaged in their entirety on e.g.: Debian. And that is just to effectively cross-compile it from another system; I doubt it's even feasible to completely do it on a conventional Android device itself, let alone to be able to actually boot the result. AFAICT the unix-y portions of it are mostly buried under layers and layers of frameworks and abstractions. System-wise it is as far from a conventional Linux or BSD software distribution as it gets and should indeed probably just be considered its own (incomplete) thing.

It's also very interesting from security point of view. Android uses a combination of UIDs and SELinux categories (or sensitivies) for each app. This makes a lot of sense, there's typically no need for app A to look at files for app B. Firejail helps a lot here by using mount namespaces and by rearranging the apps' views to the contents of $HOME, but it would be better if the OS also did something Android-like. There could be also snaps/appimages/flatpaks, but produced locally from distro packages with some distro-supported automatics.

Now, something similar could be said about the complexity of gcc/clang (either of which is currently required to build the kernel AFAIK), though there is work being done to enable smaller (and C-based) alternatives, but even disregarding that, I would consider gcc/clang to be at least more familiar beasts than the Java runtimes and what not.

The examples listed are kernel-level features, but limits.h is
system-defined and thus can be overridden by e.g.: other OS components.
#4583 is a great example of that, as glibc overrides what Linux defines in
limits.h, but musl doesn't. So keeping POSIX in mind in this case could
help with libc portability (rather than kernel portability). There is also
#4293, which was intended to make the configure script portable between
different POSIX-compliant shells (e.g.: bash and dash).
Anyway, POSIX was just an example in my previous comment; it's the only
thing that I know that explicitly defines such limits. What I meant is that
Linux/glibc/musl define related limits using the macro names specified by
POSIX, but neither Linux/glibc/musl nor POSIX define any limits for argc
AFAIK.

Good points with portability to musl. Though does any distro use it for real?

Off the top of my head, from the distros that either do or did package firejail (from README.md):
* Alpine Linux (musl)

* Void Linux (either glibc or musl)
Alpine is known for being small and so is often used on Docker containers.

postmarketOS is based on Alpine and is intended for phones (and so is much closer to a conventional distro than Android).

Void is the one that officially supports the most BSD-y userland of the list that I know of. Examples: runit, seatd, sndio.

Also, the main KISS Linux build is musl-based, but I'm not aware of any firejail build recipe.

Thanks. On Debian, musl is available, but it can't be used for pretty much anything, so I thought it's not ready for production.

@topimiettinen commented on GitHub (Oct 24, 2021): > topimiettinen commented [on Oct 23](https://github.com/netblue30/firejail/issues/4633#issuecomment-950219867): > > > > topimiettinen commented [on Oct 23](https://github.com/netblue30/firejail/issues/4633#issuecomment-950194984): > > > > > On second thought, I don't know why a limit on argc would be needed > > > > > (there is none defined by POSIX at least); I think it would only matter > > > > > on argv, because of e.g.: memory usage. > > > > > > > > > > > > It's a security feature: argv (and environment) could be used to fill the > > > > stack area so that stack smashing would be easier. Similar check exists > > > > for environment variables too. Raising the limit to ARG_MAX (524288) > > > > wouldn't be a good idea, but 128 could be raised a bit higher. > > > > > > > > > I see, that makes sense. But still, wouldn't it make more sense to check > > > only for argv (regardless of the specific upper bound number that would be > > > chosen) rather than argc? > > > > > > The important thing is actually the size, or the sum of all arguments. > > So something like this? > > ```c > int i; > size_t total_argsz = argc; > for (i = 0; i < argc; i++) { > total_argsz += strlen(argv[i]) + 1; > > if (total_argsz > SOME_ARG_MAX) > // die > } > ``` Yes. The calculation could also consider environment variables. Maybe simply (knowing the layout of argv/env/auxv in stack) just check that stack isn't used too much. <details> <summary>Off-topic discussion</summary> > > > > In general, portability to POSIX isn't very interesting for Firejail, > > > > since it depends on Linux-only features like mount namespaces, seccomp > > > > and capabilities. Without them Firejail would be useless. I don't think > > > > BSDs have anything comparable. > > > > > > > > > Never thought I'd get an appropriate occasion to do it, but: > > > I'd just like to interject for a moment. What you're referring to as Linux, > > > is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus > > > Linux. Linux is not an operating system unto itself, but rather another > > > free component of a fully functioning GNU system made useful by the GNU > > > corelibs, shell utilities and vital system components comprising a full OS > > > as defined by POSIX. > > > > > > I think calling a system GNU is exaggerating, there are many other non-GNU > > components in the system too and the distros also put a lot of effort to > > integration. The most important piece these days is the browser, which isn't > > GNU and a lot of old UNIX-like GNU or POSIX stuff with text UIs isn't very > > cool anymore. It isn't fair calling the phone systems 'Android' either, but > > calling it 'Linux/Bionic' would be silly. > > The copypasta was posted mostly in jest to point out that there is more to POSIX than the kernel-related functions and the C extensions. I think that the main point is to remind people that the shell, coreutils, make and the compiler are essential parts of the OS (as in, you couldn't even build the Linux kernel without them), which are also all specified by POSIX. You can have a "complete" (i.e.: self-bootstrapping) Linux software distribution (GNU or not) without a web browser, but probably not without the aforementioned tools. That is, everything else could be considered an application built on top of the OS, not the OS itself. We're approaching the point where shell and other utils aren't used very much for lauching apps in for the typical installation: kernel -> systemd -> sddm -> 'systemd --user' -> app (browser etc.). Also the development is done more and more in the cloud, like this GitHub. With [vscode.dev](https://vscode.dev/) it's probably possible to do all development, including editing, remotely. With Meson build system, a shell isn't necessary when compiling and it's much saner (and faster) than Make. Perhaps Firejail should switch to Meson at some point. I've actually long wanted a system, which would have two operating modes: - production, max security mode: root user not allowed, minimal software: no dev tools, shells, compilers, coreutils; as much as possible strictly read-only (squashfs), full net access - development / system administration mode where system can be updated, configuration can be edited and the production mode image can be generated, but only limited (only distro package repos) or no net access Requiring a reboot to switch modes or even switch Secure Boot on/off from UEFI BIOS could be OK. Maybe the production image could be even produced by a CI job far away. > > As for Android, it takes an absurd amount of disk space (in the realm of multiple GiB with all the tooling last I checked) just to build a normal application, let alone the entire system (it requires dozens of GiB AFAIK). And I'm not sure that all of the necessary tools are even available under FLOSS licenses, let alone packaged in their entirety on e.g.: Debian. And that is just to effectively cross-compile it from another system; I doubt it's even feasible to completely do it on a conventional Android device itself, let alone to be able to actually boot the result. AFAICT the unix-y portions of it are mostly buried under layers and layers of frameworks and abstractions. System-wise it is as far from a conventional Linux or BSD software distribution as it gets and should indeed probably just be considered its own (incomplete) thing. It's also very interesting from security point of view. Android uses a combination of UIDs and SELinux categories (or sensitivies) for each app. This makes a lot of sense, there's typically no need for app A to look at files for app B. Firejail helps a lot here by using mount namespaces and by rearranging the apps' views to the contents of $HOME, but it would be better if the OS also did something Android-like. There could be also snaps/appimages/flatpaks, but produced locally from distro packages with some distro-supported automatics. > > Now, something similar could be said about the complexity of gcc/clang (either of which is currently required to build the kernel AFAIK), though there is work being done to enable smaller (and C-based) alternatives, but even disregarding that, I would consider gcc/clang to be at least more familiar beasts than the Java runtimes and what not. </details> > > > The examples listed are kernel-level features, but limits.h is > > > system-defined and thus can be overridden by e.g.: other OS components. > > > #4583 is a great example of that, as glibc overrides what Linux defines in > > > limits.h, but musl doesn't. So keeping POSIX in mind in this case could > > > help with libc portability (rather than kernel portability). There is also > > > #4293, which was intended to make the configure script portable between > > > different POSIX-compliant shells (e.g.: bash and dash). > > > Anyway, POSIX was just an example in my previous comment; it's the only > > > thing that I know that explicitly defines such limits. What I meant is that > > > Linux/glibc/musl define related limits using the macro names specified by > > > POSIX, but neither Linux/glibc/musl nor POSIX define any limits for argc > > > AFAIK. > > > > > > Good points with portability to musl. Though does any distro use it for real? > > Off the top of my head, from the distros that either do or did package firejail (from README.md): > > * Alpine Linux (musl) > > * Void Linux (either glibc or musl) > > > Alpine is known for being small and so is often used on Docker containers. > > postmarketOS is based on Alpine and is intended for phones (and so is much closer to a conventional distro than Android). > > Void is the one that officially supports the most BSD-y userland of the list that I know of. Examples: runit, seatd, sndio. > > Also, the main KISS Linux build is musl-based, but I'm not aware of any firejail build recipe. Thanks. On Debian, musl is available, but it can't be used for pretty much anything, so I thought it's not ready for production.

gitea-mirror commented

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

Author

Owner

@Antiz96 commented on GitHub (Feb 6, 2025):

Do I understand correctly that we currently have no way to override / get round this hardcoded limit (apart from patching it at build time)?

I'm also hit by this when building Arch Linux packages containing a huge number of split packages (> 128) on our build server. Indeed, rsync fails with e.g. Error: too many arguments: argc (307) >= MAX_ARGS (128) when trying to download files once the build is over (https://gitlab.archlinux.org/archlinux/devtools/-/issues/267).

@Antiz96 commented on GitHub (Feb 6, 2025): Do I understand correctly that we currently have no way to override / get round this hardcoded limit (apart from patching it at build time)? I'm also hit by this when building Arch Linux packages containing a huge number of split packages (> 128) on our build server. Indeed, `rsync` fails with e.g. `Error: too many arguments: argc (307) >= MAX_ARGS (128)` when trying to download files once the build is over (https://gitlab.archlinux.org/archlinux/devtools/-/issues/267).

gitea-mirror commented

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

Author

Owner

@Antiz96 commented on GitHub (Feb 6, 2025):

Raising the limit to ARG_MAX (524288) wouldn't be a good idea, but 128 could be raised a bit higher.

Seeing that the current limit seems to cause some issues for people (see also https://github.com/netblue30/firejail/issues/3851) it'd indeed be great to raise it higher (if that's still reasonable regarding the security feature it covers) 😃

@Antiz96 commented on GitHub (Feb 6, 2025): > Raising the limit to ARG_MAX (524288) wouldn't be a good idea, but 128 could be raised a bit higher. Seeing that the current limit seems to cause some issues for people (see also https://github.com/netblue30/firejail/issues/3851) it'd indeed be great to raise it higher (if that's still reasonable regarding the security feature it covers) 😃

gitea-mirror commented

2026-05-05 09:24:00 -06:00

Author

Owner

@hlein commented on GitHub (May 18, 2025):

Just ran into this again, a number of packages can't compile on Gentoo when various *sum tools are firejailed, they'll die like:

...
-- Installing: /var/tmp/portage/dev-libs/protobuf-30.2/image/usr/lib64/cmake/protobuf/protobuf-options.cmake
Error: too many arguments: argc (166) >= MAX_ARGS (128)
 * ERROR: dev-libs/protobuf-30.2::gentoo failed (install phase):
...
 * The specific snippet of code:
 *       cksum=$(_multilib_header_cksum) || die;

Same for various others.

_multilib_header_cksum is defined in eclass/multilib-build.eclass and it does a find ... -exec chksum {} + - behaves similar to xargs. chksum is wrapped by firecfg by default.

So this points out anything that uses find ... -exec ... {} + or xargs and runs a firejail'ed process is prone to failure. When bulding a couple hundred packages, these all failed this way:

# find /var/tmp/portage/ -name build.log | xargs egrep -l MAX_ARGS | cut -d/ -f5,6 | uniq
dev-libs/icu-77.1
dev-libs/boost-1.88.0-r1
dev-libs/protobuf-30.2
media-video/ffmpeg-7.1.1-r1
app-crypt/rpm-sequoia-1.8.0
media-libs/opencv-4.11.0
app-misc/binwalk-3.1.0-r1
llvm-core/clang-19.1.7
llvm-core/llvm-20.1.5
x11-libs/wxGTK-3.2.8

The largest of which being:

# find /var/tmp/portage/ -name build.log | xargs egrep MAX_ARGS | cut -d\( -f2 | cut -d\) -f1 | sort -rn | head -n1
1438

Of course this is just one set of examples. Even if we lifted MAX_ARGS to something higher, any time it doesn't match what other tools on the system like find and xargs would see/determine, it's unsafe to firejail basically anything that is used in a pipeline like that.

It looks like xargs limits by max argument-string length of 128KiB.

That doesn't mean 128KiB max args, since each one is a string so needs a null terminator. So 64KiB MAX_ARGS would be required to not cause unexpected failures with xargs.

And in a quick test find ... -exec {} + with gobs of input files, it started splitting at about 113581 bytes worth of filenames w/trailing-nulls. You couldn't get more than 64KiB unique filenames, you'd need multi-character filenames and/or subdirs. So if we raised MAX_ARGS to 64KiB for the sake of xargs, it would be enough for find ... -exec {} + as well.

So then I wonder, should MAX_ARGS simply be raised, or should this be something tunable in profiles, so any program that can't reasonably be used in an invocation like this, can impose a lower limit for itself? I could see enforcing a low limit for any X apps, for example, maybe curses apps, etc.

@hlein commented on GitHub (May 18, 2025): Just ran into this again, a number of packages can't compile on Gentoo when various `*sum` tools are firejailed, they'll die like: ``` ... -- Installing: /var/tmp/portage/dev-libs/protobuf-30.2/image/usr/lib64/cmake/protobuf/protobuf-options.cmake Error: too many arguments: argc (166) >= MAX_ARGS (128) * ERROR: dev-libs/protobuf-30.2::gentoo failed (install phase): ... * The specific snippet of code: * cksum=$(_multilib_header_cksum) || die; ``` Same for various others. `_multilib_header_cksum` is defined in `eclass/multilib-build.eclass` and it does a `find ... -exec chksum {} +` - behaves similar to `xargs`. `chksum` is wrapped by `firecfg` by default. So this points out anything that uses `find ... -exec ... {} +` or `xargs` and runs a firejail'ed process is prone to failure. When bulding a couple hundred packages, these all failed this way: ``` # find /var/tmp/portage/ -name build.log | xargs egrep -l MAX_ARGS | cut -d/ -f5,6 | uniq dev-libs/icu-77.1 dev-libs/boost-1.88.0-r1 dev-libs/protobuf-30.2 media-video/ffmpeg-7.1.1-r1 app-crypt/rpm-sequoia-1.8.0 media-libs/opencv-4.11.0 app-misc/binwalk-3.1.0-r1 llvm-core/clang-19.1.7 llvm-core/llvm-20.1.5 x11-libs/wxGTK-3.2.8 ``` The largest of which being: ``` # find /var/tmp/portage/ -name build.log | xargs egrep MAX_ARGS | cut -d$ -f2 | cut -d$ -f1 | sort -rn | head -n1 1438 ``` Of course this is just one set of examples. Even if we lifted `MAX_ARGS` to something higher, any time it doesn't match what other tools on the system like `find` and `xargs` would see/determine, it's unsafe to `firejail` basically anything that is used in a pipeline like that. It looks like `xargs` limits by max argument-string length of 128KiB. That doesn't mean 128KiB max args, since each one is a string so needs a null terminator. So 64KiB `MAX_ARGS` would be required to not cause unexpected failures with `xargs`. And in a quick test `find ... -exec {} + ` with gobs of input files, it started splitting at about 113581 bytes worth of filenames w/trailing-nulls. You couldn't get more than 64KiB unique filenames, you'd need multi-character filenames and/or subdirs. So if we raised `MAX_ARGS` to 64KiB for the sake of `xargs`, it would be enough for `find ... -exec {} + ` as well. So then I wonder, should `MAX_ARGS` simply be raised, or should this be something tunable in profiles, so any program that can't reasonably be used in an invocation like this, can impose a lower limit for itself? I could see enforcing a low limit for any X apps, for example, maybe curses apps, etc.

gitea-mirror commented

2026-05-05 09:24:00 -06:00

Author

Owner

@kmk3 commented on GitHub (May 19, 2025):

Just ran into this again, a number of packages can't compile on Gentoo when
various *sum tools are firejailed, they'll die like:
...
-- Installing: /var/tmp/portage/dev-libs/protobuf-30.2/image/usr/lib64/cmake/protobuf/protobuf-options.cmake
Error: too many arguments: argc (166) >= MAX_ARGS (128)
 * ERROR: dev-libs/protobuf-30.2::gentoo failed (install phase):
...
 * The specific snippet of code:
 *       cksum=$(_multilib_header_cksum) || die;
Same for various others.

_multilib_header_cksum is defined in eclass/multilib-build.eclass and it
does a find ... -exec chksum {} + - behaves similar to xargs. chksum is
wrapped by firecfg by default.

So this points out anything that uses find ... -exec ... {} + or xargs
and runs a firejail'ed process is prone to failure. When bulding a couple
hundred packages, these all failed this way:

[...]

Thanks for the details.

I also have had issues with some basic tools being inadvertently firejailed
while building packages, for example:

#4039

I think it would make sense to disable all *sum tools in firecfg.

(And maybe also all other POSIX utils/coreutils that need to access files)

So then I wonder, should MAX_ARGS simply be raised, or should this be
something tunable in profiles, so any program that can't reasonably be used
in an invocation like this, can impose a lower limit for itself?

This would probably defeat the point of having the limit, as it seems to be
intended to reduce potential damage from just running firejail itself with a
custom profile / arguments.

@kmk3 commented on GitHub (May 19, 2025): > Just ran into this again, a number of packages can't compile on Gentoo when > various `*sum` tools are firejailed, they'll die like: > > ``` > ... > -- Installing: /var/tmp/portage/dev-libs/protobuf-30.2/image/usr/lib64/cmake/protobuf/protobuf-options.cmake > Error: too many arguments: argc (166) >= MAX_ARGS (128) > * ERROR: dev-libs/protobuf-30.2::gentoo failed (install phase): > ... > * The specific snippet of code: > * cksum=$(_multilib_header_cksum) || die; > ``` > > Same for various others. > > `_multilib_header_cksum` is defined in `eclass/multilib-build.eclass` and it > does a `find ... -exec chksum {} +` - behaves similar to `xargs`. `chksum` is > wrapped by `firecfg` by default. > > So this points out anything that uses `find ... -exec ... {} +` or `xargs` > and runs a firejail'ed process is prone to failure. When bulding a couple > hundred packages, these all failed this way: > > [...] Thanks for the details. I also have had issues with some basic tools being inadvertently firejailed while building packages, for example: * #4039 I think it would make sense to disable all `*sum` tools in firecfg. (And maybe also all other POSIX utils/coreutils that need to access files) > So then I wonder, should `MAX_ARGS` simply be raised, or should this be > something tunable in profiles, so any program that can't reasonably be used > in an invocation like this, can impose a lower limit for itself? This would probably defeat the point of having the limit, as it seems to be intended to reduce potential damage from just running firejail itself with a custom profile / arguments.

gitea-mirror commented

2026-05-05 09:24:01 -06:00

Author

Owner

@kmk3 commented on GitHub (May 20, 2025):

Besides Gentoo/hashers, there was a build issue affecting Arch/archivers:

#3095
#3097

It looks like the potential issues with package building and checksum tools was
discussed in the PR that added them:

https://github.com/netblue30/firejail/pull/4069#issuecomment-798997164

@kmk3 commented on GitHub (May 20, 2025): Besides Gentoo/hashers, there was a build issue affecting Arch/archivers: * #3095 * #3097 It looks like the potential issues with package building and checksum tools was discussed in the PR that added them: * <https://github.com/netblue30/firejail/pull/4069#issuecomment-798997164>

gitea-mirror commented

2026-05-05 09:24:01 -06:00

Author

Owner

@hlein commented on GitHub (May 22, 2025):

So then I wonder, should MAX_ARGS simply be raised, or should this be
something tunable in profiles, so any program that can't reasonably be used
in an invocation like this, can impose a lower limit for itself?

This would probably defeat the point of having the limit, as it seems to be intended to reduce potential damage from just running firejail itself with a custom profile / arguments.

Oh, interesting, you mean as self-protection for firejail itself? Or do you just mean that if not otherwise stated, the limit should default to low? That sounds like a better approach, could have a low default and a max-args profile setting that can raise it?

I saw https://github.com/netblue30/firejail/pull/6755/commits/e4365a8bc725ea3b73932c5a49e3638a8f90e029 and I think that's the right call for now regardless; it is too bad that this means we can't have any firejail protections in these cases, but it'll reduce surprise failures which will be good overall.

@hlein commented on GitHub (May 22, 2025): > > So then I wonder, should `MAX_ARGS` simply be raised, or should this be > > something tunable in profiles, so any program that can't reasonably be used > > in an invocation like this, can impose a lower limit for itself? > > This would probably defeat the point of having the limit, as it seems to be intended to reduce potential damage from just running firejail itself with a custom profile / arguments. Oh, interesting, you mean as self-protection for firejail itself? Or do you just mean that if not otherwise stated, the limit should default to low? That sounds like a better approach, could have a low default and a `max-args` profile setting that can raise it? I saw https://github.com/netblue30/firejail/pull/6755/commits/e4365a8bc725ea3b73932c5a49e3638a8f90e029 and I think that's the right call for now regardless; it is too bad that this means we can't have any firejail protections in these cases, but it'll reduce surprise failures which will be good overall.

gitea-mirror commented

2026-05-05 09:24:01 -06:00

Author

Owner

@kmk3 commented on GitHub (May 23, 2025):

This would probably defeat the point of having the limit, as it seems to be
intended to reduce potential damage from just running firejail itself with
a custom profile / arguments.

Oh, interesting, you mean as self-protection for firejail itself? Or do you
just mean that if not otherwise stated, the limit should default to low? That
sounds like a better approach, could have a low default and a max-args
profile setting that can raise it?

The former; see the comments from 2021 in this thread.

Rows
Columns

[GH-ISSUE #4633] Higher argument limits? (Error: too many arguments) #2732