From: Alejandro Colomar <alx@kernel.org>
To: Rik van Riel <riel@surriel.com>
Cc: linux-man@vger.kernel.org, kernel-team@meta.com,
linux-kernel@vger.kernel.org,
Matthew House <mattlloydhouse@gmail.com>,
Eric Biederman <ebiederm@xmission.com>
Subject: Re: [PATCH v5] execve.2: execve also returns E2BIG if a string is too long
Date: Thu, 12 Oct 2023 11:03:04 +0200 [thread overview]
Message-ID: <ZSe2SNGy9dMWil3w@debian> (raw)
In-Reply-To: <20231011214652.1c4db8b7@imladris.surriel.com>
[-- Attachment #1: Type: text/plain, Size: 3318 bytes --]
Hi Rik,
On Wed, Oct 11, 2023 at 09:46:52PM -0400, Rik van Riel wrote:
> The execve syscall returns -E2BIG in 3 cases:
> - The total length of the command line arguments and environment is too large.
> - An argument or environment string (including the NUL byte) is longer than MAX_ARG_STRLEN.
> - The full path to the executable (including the NUL byte) exceeds MAX_ARG_STRLEN.
I changed the above to fit in 72 columns.
>
> Spell out all 3 cases in the -E2BIG section.
>
> Discovered by moving a too large commandline parameter to an environment
> variable, and finding that things still did not work. Examined the code
> in fs/exec.c to get the details.
>
> This simple shell script starts failing at 2^17 on a system with 4kB
> page size:
> ./exec2big.sh: line 10: /bin/true: Argument list too long
> fork failed at loop 17
Moved this to after the script.
>
> #!/bin/sh
And indented the script to avoid issues with git and hashes in commit
messages.
> STRING="a"
>
> for loop in `seq 20`; do
> STRING="$STRING$STRING"
> export STRING
> if /bin/true ; then
> : # still under the limit
> else
> echo "fork failed at loop $loop"
> fi
> done
>
> Signed-off-by: Rik van Riel <riel@surriel.com>
> Suggested-by: Matthew House <mattlloydhouse@gmail.com>
And reordered this.
Patch applied. :)
<https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=39a4ac5820cbdc8c9f7ebaad70f1adcc59955cbb>
> ---
> man2/execve.2 | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/man2/execve.2 b/man2/execve.2
> index 0d9582492ad1..b689101771e5 100644
> --- a/man2/execve.2
> +++ b/man2/execve.2
> @@ -449,7 +449,12 @@ The total number of bytes in the environment
> .RI ( envp )
> and argument list
> .RI ( argv )
> -is too large.
> +is too large,
> +an argument or environment string is too long,
> +or the full
> +.I pathname
> +of the executable is too long.
> +The terminating NUL is counted as part of the string length.
I replaced s/NUL/null byte/
man-pages(7):
NULL, NUL, null pointer, and null byte
A null pointer is a pointer that points to nothing, and is nor‐
mally indicated by the constant NULL. On the other hand, NUL
is the null byte, a byte with the value 0, represented in C via
the character constant '\0'.
The preferred term for the pointer is "null pointer" or simply
"NULL"; avoid writing "NULL pointer".
The preferred term for the byte is "null byte". Avoid writing
"NUL", since it is too easily confused with "NULL". Avoid also
the terms "zero byte" and "null character". The byte that ter‐
minates a C string should be described as "the terminating null
byte"; strings may be described as "null‐terminated", but avoid
the use of "NUL‐terminated".
I kept NUL in the commit message, because I actually like using NUL, but
Michael didn't, and for consistency, I keep that in the body of the
manual pages. In the commit message, it's fine for me.
Cheers,
Alex
> .TP
> .B EACCES
> Search permission is denied on a component of the path prefix of
> --
> 2.41.0
>
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2023-10-12 9:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 1:46 [PATCH v5] execve.2: execve also returns E2BIG if a string is too long Rik van Riel
2023-10-12 9:03 ` Alejandro Colomar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZSe2SNGy9dMWil3w@debian \
--to=alx@kernel.org \
--cc=ebiederm@xmission.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mattlloydhouse@gmail.com \
--cc=riel@surriel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox