2023-10-11 16:43:41

by Rik van Riel

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

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 <[email protected]>
Suggested-by: Matthew House <[email protected]>
---
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



2023-10-11 16:53:42

by Rik van Riel

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

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 <[email protected]>
Suggested-by: Matthew House <[email protected]>
---
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


2023-10-11 20:11:46

by Alejandro Colomar

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

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


Attachments:
(No filename) (732.00 B)
signature.asc (849.00 B)
Download all attachments

2023-10-11 20:16:10

by Alejandro Colomar

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

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 <[email protected]>
> Suggested-by: Matthew House <[email protected]>
> ---
> 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/>


Attachments:
(No filename) (2.38 kB)
signature.asc (849.00 B)
Download all attachments

2023-10-11 20:53:51

by Rik van Riel

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

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.

2023-10-11 23:46:32

by Alejandro Colomar

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

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


Attachments:
(No filename) (1.56 kB)
signature.asc (849.00 B)
Download all attachments