Thread (4 messages) 4 messages, 3 authors, 2021-07-03

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

flat view

From: Walter Harms <hidden>
Date: 2021-06-25 10:34:00

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 [off-list ref]
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help