execve(2) man page: "absolute pathname" inconsistency

execve(2) man page: "absolute pathname" inconsistency

[Nora Platiel]

Hello,
I'm reporting a problem with the execve(2) man page (see the "absolute pathname" part):

> If the pathname argument of execve() specifies an interpreter
> script, then interpreter will be invoked with the following
> arguments:
>
>     interpreter [optional-arg] pathname arg...
>
> where pathname is the absolute pathname of the file specified as
>                       ^^^^^^^^^^^^^^^^^
> the first argument of execve(), and arg...  is the series of
> words pointed to by the argv argument of execve(), starting at
> argv[1].  Note that there is no way to get the argv[0] that was
> passed to the execve() call.

Then in the final example:

> $ ./execve ./script
> argv[0]: ./myecho
> argv[1]: script-arg
> argv[2]: ./script
> argv[3]: hello
> argv[4]: world

According to the description, argv[2] is supposed to be the *absolute pathname* of "./script" but it is not.
(In path_resolution(7), an absolute pathname is defined to be a pathname starting with a '/' character.)

I tested the example with kernel 4.4.246 and the output is the same as the one in the man page (relative paths are preserved).
I don't know about newer kernels, but if I understand correctly, either the "absolute pathname" wording is incorrect or the example is.
(In the latter case, perhaps the man page could also mention the change in behavior.)

The "absolute pathname" wording was introduced here:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=60f16bf2fe6bd2d2d001d0a41936e778b1e7e3f6
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=63059c4b527d0da73666da5ff29dcc902e219371

Regards,
NP

AW: execve(2) man page: "absolute pathname" inconsistency

[Walter Harms]

I guess there is a mixup between interpreter and  pathname.

All this is only vaild if the
flag is set to P (P - preserve-argv[0]) when you add a new
setting in  /proc/sys/fs/binfmt_misc/register
(any way to get the current setting ?)

the original wording from the kernel says:

Legacy behavior of binfmt_misc is to overwrite the original argv[0] with the full path to the binary. When this flag is included, binfmt_misc will add an argument to the argument vector for this purpose, thus preserving the original argv[0]. e.g. If your interp is set to /bin/foo and you run blah (which is in /usr/local/bin), then the kernel will execute /bin/foo with argv[] set to ["/bin/foo", "/usr/local/bin/blah", "blah"]. The interp has to be aware of this so it can execute /usr/local/bin/blah with argv[] set to ["blah"].

re,
 wh
________________________________________
Von: Nora Platiel <nplatiel@gmx.us>
Gesendet: Donnerstag, 24. Juni 2021 22:42:08
An: mtk.manpages@gmail.com; alx.manpages@gmail.com
Cc: linux-man@vger.kernel.org
Betreff: execve(2) man page: "absolute pathname" inconsistency

WARNUNG: Diese E-Mail kam von außerhalb der Organisation. Klicken Sie nicht auf Links oder öffnen Sie keine Anhänge, es sei denn, Sie kennen den/die Absender*in und wissen, dass der Inhalt sicher ist.


Hello,
I'm reporting a problem with the execve(2) man page (see the "absolute pathname" part):

> If the pathname argument of execve() specifies an interpreter
> script, then interpreter will be invoked with the following
> arguments:
>
>     interpreter [optional-arg] pathname arg...
>
> where pathname is the absolute pathname of the file specified as
>                       ^^^^^^^^^^^^^^^^^
> the first argument of execve(), and arg...  is the series of
> words pointed to by the argv argument of execve(), starting at
> argv[1].  Note that there is no way to get the argv[0] that was
> passed to the execve() call.

Then in the final example:

> $ ./execve ./script
> argv[0]: ./myecho
> argv[1]: script-arg
> argv[2]: ./script
> argv[3]: hello
> argv[4]: world

According to the description, argv[2] is supposed to be the *absolute pathname* of "./script" but it is not.
(In path_resolution(7), an absolute pathname is defined to be a pathname starting with a '/' character.)

I tested the example with kernel 4.4.246 and the output is the same as the one in the man page (relative paths are preserved).
I don't know about newer kernels, but if I understand correctly, either the "absolute pathname" wording is incorrect or the example is.
(In the latter case, perhaps the man page could also mention the change in behavior.)

The "absolute pathname" wording was introduced here:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=60f16bf2fe6bd2d2d001d0a41936e778b1e7e3f6
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=63059c4b527d0da73666da5ff29dcc902e219371

Regards,
NP

Re: AW: execve(2) man page: "absolute pathname" inconsistency

[Nora Platiel]

> I guess there is a mixup between interpreter and pathname.

Do you mean that `interpreter' is supposed to be absolute, instead of `pathname'?
The same example also disproves that, since argv[0] is relative:

|   interpreter [optional-arg] pathname arg...
|
| $ ./execve ./script
| argv[0]: ./myecho
| argv[1]: script-arg
| argv[2]: ./script
| argv[3]: hello
| argv[4]: world

> All this is only vaild if the
> flag is set to P (P - preserve-argv[0]) when you add a new
> setting in /proc/sys/fs/binfmt_misc/register

I'm not sure how binfmt_misc is related to this.
We are talking about the normal shebang mechanism (which doesn't preserve argv[0]), and the man page doesn't even mention binfmt_misc.
Do you agree that the man page is in error?

> (any way to get the current setting ?)

You can see the active flags for a registered FORMAT by reading /proc/sys/fs/binfmt_misc/FORMAT.
(Though I'm new to binfmt_misc, I usually keep it disabled.)

> the original wording from the kernel says:
>
> Legacy behavior of binfmt_misc is to overwrite the original argv[0] with
> the full path to the binary. When this flag is included, binfmt_misc will
> add an argument to the argument vector for this purpose, thus preserving
> the original argv[0]. e.g. If your interp is set to /bin/foo and you run
> blah (which is in /usr/local/bin), then the kernel will execute /bin/foo
> with argv[] set to ["/bin/foo", "/usr/local/bin/blah", "blah"]. The interp
> has to be aware of this so it can execute /usr/local/bin/blah with argv[]
> set to ["blah"].

According to my tests, no path is ever made absolute regardless of the P flag.
Apparently where it says "the full path to the binary" it doesn't mean an absolute path, just a path that resolves to the actual file (and doesn't need to be searched in $PATH as it may be the case with the original argv[0]).

# echo :myecho:M::1::./myecho: >/proc/sys/fs/binfmt_misc/register
# echo :myechop:M::2::./myecho:P >/proc/sys/fs/binfmt_misc/register
$ cat /proc/sys/fs/binfmt_misc/myecho
enabled
interpreter ./myecho
flags:
offset 0
magic 31
$ cat /proc/sys/fs/binfmt_misc/myechop
enabled
interpreter ./myecho
flags: P
offset 0
magic 32
$ echo 1 >script
$ echo 2 >scriptp
$ chmod a+x script scriptp
$ ./execve ./script
argv[0]: ./myecho
argv[1]: ./script
argv[2]: hello
argv[3]: world
$ ./execve ./scriptp
argv[0]: ./myecho
argv[1]: ./scriptp
argv[2]: ./scriptp
argv[3]: hello
argv[4]: world

As you can see, all the paths are relative regardless of the P flag.

Re: execve(2) man page: "absolute pathname" inconsistency

[Alejandro Colomar (man-pages)]

Hi Nora,

On 6/24/21 10:42 PM, Nora Platiel wrote:
> Hello,
> I'm reporting a problem with the execve(2) man page (see the "absolute pathname" part):
> 
>> If the pathname argument of execve() specifies an interpreter
>> script, then interpreter will be invoked with the following
>> arguments:
>>
>>     interpreter [optional-arg] pathname arg...
>>
>> where pathname is the absolute pathname of the file specified as
>>                       ^^^^^^^^^^^^^^^^^
>> the first argument of execve(), and arg...  is the series of
>> words pointed to by the argv argument of execve(), starting at
>> argv[1].  Note that there is no way to get the argv[0] that was
>> passed to the execve() call.
> 
> Then in the final example:
> 
>> $ ./execve ./script
>> argv[0]: ./myecho
>> argv[1]: script-arg
>> argv[2]: ./script
>> argv[3]: hello
>> argv[4]: world
> 
> According to the description, argv[2] is supposed to be the *absolute pathname* of "./script" but it is not.
> (In path_resolution(7), an absolute pathname is defined to be a pathname starting with a '/' character.)
> 
> I tested the example with kernel 4.4.246 and the output is the same as the one in the man page (relative paths are preserved).
> I don't know about newer kernels, but if I understand correctly, either the "absolute pathname" wording is incorrect or the example is.
> (In the latter case, perhaps the man page could also mention the change in behavior.)
> 
> The "absolute pathname" wording was introduced here:
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=60f16bf2fe6bd2d2d001d0a41936e778b1e7e3f6
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=63059c4b527d0da73666da5ff29dcc902e219371

Thanks for all of the info and links.

I think you're right.  In fact, POSIX talks about pathname, and not
absolute pathname
(<https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html>).

However, the kernel documentation talks about 'full path', so I'm not
sure if maybe some versions of the kernel did not support relative paths
 (<https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html>).

I added Shawn to the thread, so maybe he can shed some light (he added
that text).

Regards,

Alex


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: execve(2) man page: "absolute pathname" inconsistency

[Nora Platiel]

On 2021-07-03 21:58, Shawn Landden wrote:
> The absolute pathname is available in the Linux-specific auxiliary-vector
> feature. Here is a suggested patch:

I haven't made sense of the comment on the last added line, but the "visible" part looks good to me.
Thanks,
NP

> diff --git a/man2/execve.2 b/man2/execve.2
> index c18ca5412..66a18af27 100644
> --- a/man2/execve.2
> +++ b/man2/execve.2
> @@ -344,20 +344,27 @@ will be invoked with the following arguments:
> .EE
> .in
> .PP
> where
> .I pathname
> -is the absolute pathname of the file specified as the first argument of
> +is the pathname of the file specified (may be relative to
> +.Br getcwd (3)
> +of the caller) as the first argument of
> .BR execve (),
> and
> .I arg...
> is the series of words pointed to by the
> .I argv
> argument of
> .BR execve (),
> starting at
> .IR argv[1] .
> +The absolute pathname of the script is also available in same auxiliary vector the environment and argument variables are in, as
> +.BR AT_EXECFN .
> +See
> +.BR getauxval (3).
> +,\" I am not sure if this claim is as clear as it can be, but we are already wasting so much memory for these so.....it would be possible to copy what is needed out of the environment, and then move the stack back into the massive environment vector Linux passes (and which has an almost unbounded size).
> Note that there is no way to get the
> .IR argv[0]
> that was passed to the
> .BR execve ()
> call.
> --
> 2.30.2

Re: execve(2) man page: "absolute pathname" inconsistency

[Alejandro Colomar (man-pages)]

Hi Nora and Shawn,

On 7/15/21 6:09 PM, Nora Platiel wrote:
> On 2021-07-03 21:58, Shawn Landden wrote:
>> The absolute pathname is available in the Linux-specific auxiliary-vector
>> feature. Here is a suggested patch:
> 
> I haven't made sense of the comment on the last added line, but the "visible" part looks good to me.

Thanks for the review!  Mind if I add a Reviewed-by line?

I also couldn't understand the comment so much.  Shawn, would you mind
to explain it (or just remove it)?

Thanks,

Alex
> 
>> diff --git a/man2/execve.2 b/man2/execve.2
>> index c18ca5412..66a18af27 100644
>> --- a/man2/execve.2
>> +++ b/man2/execve.2
>> @@ -344,20 +344,27 @@ will be invoked with the following arguments:
>> .EE
>> .in
>> .PP
>> where
>> .I pathname
>> -is the absolute pathname of the file specified as the first argument of
>> +is the pathname of the file specified (may be relative to
>> +.Br getcwd (3)
>> +of the caller) as the first argument of
>> .BR execve (),
>> and
>> .I arg...
>> is the series of words pointed to by the
>> .I argv
>> argument of
>> .BR execve (),
>> starting at
>> .IR argv[1] .
>> +The absolute pathname of the script is also available in same auxiliary vector the environment and argument variables are in, as
>> +.BR AT_EXECFN .
>> +See
>> +.BR getauxval (3).
>> +,\" I am not sure if this claim is as clear as it can be, but we are already wasting so much memory for these so.....it would be possible to copy what is needed out of the environment, and then move the stack back into the massive environment vector Linux passes (and which has an almost unbounded size).
>> Note that there is no way to get the
>> .IR argv[0]
>> that was passed to the
>> .BR execve ()
>> call.
>> --
>> 2.30.2
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/