[PATCH v3] execve.2: execve also returns E2BIG if a string is too long

[PATCH v3] execve.2: execve also returns E2BIG if a string is too long

[Rik van Riel]

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 is longer than MAX_ARG_STRLEN.
- The full path to the executable exceeds MAX_ARG_STRLEN.

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

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>
---
 man2/execve.2 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/man2/execve.2 b/man2/execve.2
index 0d9582492ad1..85c6ec15df3c 100644
--- a/man2/execve.2
+++ b/man2/execve.2
@@ -449,7 +449,8 @@ 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 path name to the executable is too long.
 .TP
 .B EACCES
 Search permission is denied on a component of the path prefix of
-- 
2.41.0

[PATCH v4] execve.2: execve also returns E2BIG if a string is too long

[Rik van Riel]

Sigh, once again I did a git commit --amend without the latest file change being
included. The change below should be good. Working with both git and hg gets me sometimes :/
---8<---

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 is longer than MAX_ARG_STRLEN.
- The full path to the executable exceeds MAX_ARG_STRLEN.

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

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>
---
 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.
 .TP
 .B EACCES
 Search permission is denied on a component of the path prefix of
-- 
2.41.0

Using hg and git (Was: [PATCH v4] execve.2: execve also returns E2BIG if a string is too long)

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Hi Rik,

On Wed, Oct 11, 2023 at 12:53:30PM -0400, Rik van Riel wrote:
> Sigh, once again I did a git commit --amend without the latest file change being
> included. The change below should be good. Working with both git and hg gets me sometimes :/

Been there.  Hate that.  I hope I don't touch hg(1) anymore.  :D

Did you know about git-remote-hg(1)?  It lets you work with hg remotes
without running hg(1) at all.  It had some glitches from time to time
--TBH, I'm not sure if the glitches were from git-remote-hg(1), or just
that hg(1) is crap, or that the maintainers of the hg remote weren't so
good at it--, but nothing too irritating or destructive.

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v4] execve.2: execve also returns E2BIG if a string is too long

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

Hi Rik,

On Wed, Oct 11, 2023 at 12:53:30PM -0400, Rik van Riel wrote:
> Sigh, once again I did a git commit --amend without the latest file change being
> included. The change below should be good. Working with both git and hg gets me sometimes :/
> ---8<---
> 
> 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 is longer than MAX_ARG_STRLEN.

I'm still concerned by the wording of this sentence (and the next one).
When I (and any user-space programmer, I think) read "string is longer
than FOO", I read `strlen(string) > FOO`.  Since it's rather
`strlen(string) >= FOO`, I think you should clarify.  How about this?

-  An argument or environment string is longer (including the null byte)
   than MAX_ARG_STRLEN.

Thanks,
Alex

> - The full path to the executable exceeds MAX_ARG_STRLEN.
> 
> 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
> 
> 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

Thank you very much!

> 
> Signed-off-by: Rik van Riel <riel@surriel.com>
> Suggested-by: Matthew House <mattlloydhouse@gmail.com>
> ---
>  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.
>  .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 --]

Re: [PATCH v4] execve.2: execve also returns E2BIG if a string is too long

[Rik van Riel]

On Wed, 2023-10-11 at 22:14 +0200, Alejandro Colomar wrote:
> Hi Rik,
> 
> On Wed, Oct 11, 2023 at 12:53:30PM -0400, Rik van Riel wrote:
> > Sigh, once again I did a git commit --amend without the latest file
> > change being
> > included. The change below should be good. Working with both git
> > and hg gets me sometimes :/
> > ---8<---
> > 
> > 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 is longer than MAX_ARG_STRLEN.
> 
> I'm still concerned by the wording of this sentence (and the next
> one).
> When I (and any user-space programmer, I think) read "string is
> longer
> than FOO", I read `strlen(string) > FOO`.  Since it's rather
> `strlen(string) >= FOO`, I think you should clarify.  How about this?
> 
> -  An argument or environment string is longer (including the null
> byte)
>    than MAX_ARG_STRLEN.

That works. Would you like me to re-send a v5, or do you
want to massage the changelog when you apply the patch?

I must admit I paid more attention to the wording in the
man page than the wording in the changelog :)

-- 
All Rights Reversed.

Re: [PATCH v4] execve.2: execve also returns E2BIG if a string is too long

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

On Wed, Oct 11, 2023 at 04:53:20PM -0400, Rik van Riel wrote:
> On Wed, 2023-10-11 at 22:14 +0200, Alejandro Colomar wrote:
> > Hi Rik,
> > 
> > On Wed, Oct 11, 2023 at 12:53:30PM -0400, Rik van Riel wrote:
> > > Sigh, once again I did a git commit --amend without the latest file
> > > change being
> > > included. The change below should be good. Working with both git
> > > and hg gets me sometimes :/
> > > ---8<---
> > > 
> > > 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 is longer than MAX_ARG_STRLEN.
> > 
> > I'm still concerned by the wording of this sentence (and the next
> > one).
> > When I (and any user-space programmer, I think) read "string is
> > longer
> > than FOO", I read `strlen(string) > FOO`.  Since it's rather
> > `strlen(string) >= FOO`, I think you should clarify.  How about this?
> > 
> > -  An argument or environment string is longer (including the null
> > byte)
> >    than MAX_ARG_STRLEN.
> 
> That works. Would you like me to re-send a v5, or do you
> want to massage the changelog when you apply the patch?
> 
> I must admit I paid more attention to the wording in the
> man page than the wording in the changelog :)

I wouldn't mind doing it myself, but I'll ask you to resend, if you
don't mind.  I usually find that doing so helps catch other accidents
that I didn't catch.  :)

Cheers,
Alex

> 
> -- 
> All Rights Reversed.

:)

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]