[musl] execve with null envp

[musl] execve with null envp

[Tali Auster]

Hello,

Is there any specific behavior specified when NULL is passed for envp in 
any of the exec* methods that accept it? I took a quick look at the 
source tree, and process/execve.c has a comment suggesting that the 
correct behavior may be to use environ for envp before passing the NULL 
to the syscall unchanged. My intuition - and, in practice, Linux with 
glibc seems to agree - is that a NULL envp means an empty environment. I 
imagine the answer to this question may just be a vague shrug, but does 
POSIX mandate anything specific here? Or, perhaps a question with a more 
clear answer, can my userspace code call execve(pathname, argv, NULL) 
and reliably expect the child to have an empty environment?

Hopefully this is on-topic for this list; regardless, thanks for any 
help or direction y'all can provide!

Tali Auster
They/Them

Re: [musl] execve with null envp

[Rich Felker]

On Fri, Jun 09, 2023 at 09:05:15AM -0600, Tali Auster wrote:
> Hello,
> 
> Is there any specific behavior specified when NULL is passed for
> envp in any of the exec* methods that accept it? I took a quick look
> at the source tree, and process/execve.c has a comment suggesting
> that the correct behavior may be to use environ for envp before
> passing the NULL to the syscall unchanged. My intuition - and, in
> practice, Linux with glibc seems to agree - is that a NULL envp
> means an empty environment. I imagine the answer to this question
> may just be a vague shrug, but does POSIX mandate anything specific
> here? Or, perhaps a question with a more clear answer, can my
> userspace code call execve(pathname, argv, NULL) and reliably expect
> the child to have an empty environment?
> 
> Hopefully this is on-topic for this list; regardless, thanks for any
> help or direction y'all can provide!

The only specification I'm aware of is:

    "The argument envp is an array of character pointers to
    null-terminated strings. These strings shall constitute the
    environment for the new process image. The envp array is
    terminated by a null pointer."

So, if the caller fails to satisfy that part of the interface
contract, the behavior is undefined.

I'm not sure if there's any historical consistency on what happens
here or if any implementations have the behavior the comment suggested
might be "right", but short of research to establish that there's a
reliable behavior and effort to standardize it, I think the clear
solution here is "don't do that". It's easy to just pass (char*[]){0}
instead of a null pointer.

Rich

Re: [musl] execve with null envp

[Bobby Bingham]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

The Linux manpage explicitly says to not rely on this and that other systems are known to return EFAULT in this case.

https://www.man7.org/linux/man-pages/man2/execve.2.html#NOTES


On June 9, 2023 12:04:04 PM CDT, Rich Felker <dalias@libc.org> wrote:
>On Fri, Jun 09, 2023 at 09:05:15AM -0600, Tali Auster wrote:
>> Hello,
>> 
>> Is there any specific behavior specified when NULL is passed for
>> envp in any of the exec* methods that accept it? I took a quick look
>> at the source tree, and process/execve.c has a comment suggesting
>> that the correct behavior may be to use environ for envp before
>> passing the NULL to the syscall unchanged. My intuition - and, in
>> practice, Linux with glibc seems to agree - is that a NULL envp
>> means an empty environment. I imagine the answer to this question
>> may just be a vague shrug, but does POSIX mandate anything specific
>> here? Or, perhaps a question with a more clear answer, can my
>> userspace code call execve(pathname, argv, NULL) and reliably expect
>> the child to have an empty environment?
>> 
>> Hopefully this is on-topic for this list; regardless, thanks for any
>> help or direction y'all can provide!
>
>The only specification I'm aware of is:
>
>    "The argument envp is an array of character pointers to
>    null-terminated strings. These strings shall constitute the
>    environment for the new process image. The envp array is
>    terminated by a null pointer."
>
>So, if the caller fails to satisfy that part of the interface
>contract, the behavior is undefined.
>
>I'm not sure if there's any historical consistency on what happens
>here or if any implementations have the behavior the comment suggested
>might be "right", but short of research to establish that there's a
>reliable behavior and effort to standardize it, I think the clear
>solution here is "don't do that". It's easy to just pass (char*[]){0}
>instead of a null pointer.
>
>Rich

[-- Attachment #2: Type: text/html, Size: 2551 bytes --]