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

List:       linux-man
Subject:    Re: AW: execve(2) man page: "absolute pathname" inconsistency
From:       Nora Platiel <nplatiel () gmx ! us>
Date:       2021-06-26 23:09:34
Message-ID: trinity-606da93f-54ae-4472-ba63-e45b3f76d6b0-1624748974126 () 3c-app-mailcom-bs03
[Download RAW message or body]

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

Do you mean that `interpreter' is supposed to be absolute, instead of `pat=
hname'?
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 wil=
l
> 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 inte=
rp
> 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 f=
lag.
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 n=
eed 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.
[prev in list] [next in list] [prev in thread] [next in thread]