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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux