You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.
p5p decided to allow ENV sizes of 1^32-1 in https://rt.perl.org/Public/Bug/Display.html?id=133204
However the system limit seems to be ARG_MAX, see https://www.in-ulm.de/~mascheck/various/argmax/ which is a much lower and safer value. ~128KB
Esp. since it's not only heap but mostly stack sensitive (execve).
If you grow the environment too large, you may be unable to exec other programs properly - either the environment will be truncated or the exec operation will fail.
Catching future exec failure with a misleading error message at the root cause is preferred, esp. given the strange action at a distance and the stack sensitive nature, which might not be caught on all kernels.
I think we should rather restrict it statically at ARG_MAX, even if the dynamic cfg would allow more.
needs to be backported to 5.26 and 5.28
musl and glibc rely in the kernel to catch overlarge env, but not every system is linux.
See also the POSIX rationale not to restrict to ARG_MAX those times, which does not apply to us. http://pubs.opengroup.org/onlinepubs/9699919799/functions/setenv.html The standard developers considered requiring that setenv() indicate an error when a call to it would result in exceeding {ARG_MAX}. The requirement was rejected since the condition might be temporary, with the application eventually reducing the environment size. The ultimate success or failure depends on the size at the time of a call to exec, which returns an indication of this error condition.
The text was updated successfully, but these errors were encountered:
p5p decided to allow ENV sizes of 1^32-1 in https://rt.perl.org/Public/Bug/Display.html?id=133204
However the system limit seems to be ARG_MAX, see https://www.in-ulm.de/~mascheck/various/argmax/ which is a much lower and safer value. ~128KB
Esp. since it's not only heap but mostly stack sensitive (execve).
If you grow the environment too large, you may be unable to exec other programs properly - either the environment will be truncated or the exec operation will fail.
Catching future exec failure with a misleading error message at the root cause is preferred, esp. given the strange action at a distance and the stack sensitive nature, which might not be caught on all kernels.
I think we should rather restrict it statically at ARG_MAX, even if the dynamic cfg would allow more.
needs to be backported to 5.26 and 5.28
musl and glibc rely in the kernel to catch overlarge env, but not every system is linux.
See also the POSIX rationale not to restrict to ARG_MAX those times, which does not apply to us.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/setenv.html
The standard developers considered requiring that setenv() indicate an error when a call to it would result in exceeding {ARG_MAX}. The requirement was rejected since the condition might be temporary, with the application eventually reducing the environment size. The ultimate success or failure depends on the size at the time of a call to exec, which returns an indication of this error condition.
The text was updated successfully, but these errors were encountered: