[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-man
Subject:    AW: execve(2) man page: "absolute pathname" inconsistency
From:       Walter Harms <wharms () bfs ! de>
Date:       2021-06-25 10:33:55
Message-ID: 750acf642c3e4e79b782e72d5914c89d () bfs ! de
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]