Hi,

I write a PHP extension and I have the problem that "extern char** environ" is NULL
→ this was probably done in PHP but I don't find the position ???

The funny thing is that "getenv" return the environment variable like "PHPRC" but "environ" itself is NULL.

If I start a subprocess from my extension like:
→ posix_spawn(&pid, path, NULL, &sa, (char *const *) argv, environ)..

The new process get EMPTY environment and will probably NOT work correctly.

now my question:

1) if "getenv" work correctly but "environ" is NULL there have to be an internal "environ" used by "getenv" and
invisible by me.
2) it is possible to access the "hidden" internal "environ" to start my process ?

mfg

In article <thrg3j$5ku2$1@dont-email.me>,
aotto1968 <aotto1968@t-online.de> wrote:
>Hi,
>
>I write a PHP extension and I have the problem that "extern char** environ" is NULL
> this was probably done in PHP but I don't find the position ???
>
>The funny thing is that "getenv" return the environment variable like "PHPRC" but
>"environ" itself is NULL.
>
>If I start a subprocess from my extension like:
> posix_spawn(&pid, path, NULL, &sa, (char *const *) argv, environ)..
>
>The new process get EMPTY environment and will probably NOT work correctly.
>
>now my question:
>
>1) if "getenv" work correctly but "environ" is NULL there have to be an internal
>"environ" used by "getenv" and
> invisible by me.
>2) it is possible to access the "hidden" internal "environ" to start my process ?
>
>mfg
>

1) I am *not* the topicality police. But many are, and they will be along
any minute to harangue you for this thread being off topic.

2) Have you tried omitting the third arg to main()? Usually people do.
Usually, you invoke main() with just two args - argc and argv - and it
"just works".

--
The coronavirus is the first thing, in his 74 pathetic years of existence,
that the orange menace has come into contact with, that he couldn't browbeat,
bully, bullshit, bribe, sue, legally harrass, get Daddy to fix, get his
siblings to bail him out of, or, if all else fails, simply wish it away.

the PHP extension is a shared library → no main :-)

→ my question was more about the background of "environ" and why "getenv" return a value if environ is NULL.

On 08.10.22 14:28, Kenny McCormack wrote:
> In article <thrg3j$5ku2$1@dont-email.me>,
> aotto1968 <aotto1968@t-online.de> wrote:
>> Hi,
>>
>> I write a PHP extension and I have the problem that "extern char** environ" is NULL
>> this was probably done in PHP but I don't find the position ???
>>
>> The funny thing is that "getenv" return the environment variable like "PHPRC" but
>> "environ" itself is NULL.
>>
>> If I start a subprocess from my extension like:
>> posix_spawn(&pid, path, NULL, &sa, (char *const *) argv, environ)..
>>
>> The new process get EMPTY environment and will probably NOT work correctly.
>>
>> now my question:
>>
>> 1) if "getenv" work correctly but "environ" is NULL there have to be an internal
>> "environ" used by "getenv" and
>> invisible by me.
>> 2) it is possible to access the "hidden" internal "environ" to start my process ?
>>
>> mfg
>>
>
> 1) I am *not* the topicality police. But many are, and they will be along
> any minute to harangue you for this thread being off topic.
>
> 2) Have you tried omitting the third arg to main()? Usually people do.
> Usually, you invoke main() with just two args - argc and argv - and it
> "just works".

On 10/8/2022 6:39 PM, aotto1968 wrote:
> the PHP extension is a shared library → no main :-)
>
> → my question was more about the background of "environ" and why
> "getenv" return a value if environ is NULL.
>

You mention posix_spawn : that points to POSIX as source for information
on what it does, rather than the C language. I'd look there.

The following is part of the C language, though:

getenv (n2176 7.22.4.6)
"The getenv function searches an environment list, provided by the
host environment, for a string that matches the string pointed to by
name. The set of environment names and the method for altering the
environment list are implementation-defined...""

That is, getenv is entirely implementation defined, but it is specified
to exist. More info has to come from your implementation.

Incidentally:
main (n2176 5.1.2.2.1)
"The function called at program startup is named main."
...
"It shall be defined with a return type of int and with no parameters"
...
"or with two parameters (referred to here as argc and argv,"
...
"or in some other implementation-defined manner"

That is, the standard allows for, but gives no explicit specification
for a third parameter to main (unlike POSIX)

>
> On 08.10.22 14:28, Kenny McCormack wrote:
> > In article <thrg3j$5ku2$1@dont-email.me>,
> > aotto1968  <aotto1968@t-online.de> wrote:
> >> Hi,
> >>
> >> I write a PHP extension and I have the problem that "extern char**
> environ" is NULL
> >> this was probably done in PHP but I don't find the position ???
> >>
> >> The funny thing is that "getenv" return the environment variable
> like "PHPRC" but
> >> "environ" itself is NULL.
> >>
> >> If I start a subprocess from my extension like:
> >> posix_spawn(&pid, path, NULL, &sa, (char *const *) argv, environ)..
> >>
> >> The new process get EMPTY environment and will probably NOT work
> correctly.
> >>
> >> now my question:
> >>
> >> 1) if "getenv" work correctly but "environ" is NULL there have to be
> an internal
> >> "environ" used by "getenv" and
> >>     invisible by me.
> >> 2) it is possible to access the "hidden" internal "environ" to start
> my process ?
> >>
> >> mfg
> >>
> >
> > 1) I am *not* the topicality police.  But many are, and they will be
> along
> > any minute to harangue you for this thread being off topic.
> >
> > 2) Have you tried omitting the third arg to main()?  Usually people do.
> > Usually, you invoke main() with just two args - argc and argv - and it
> > "just works".
>

aotto1968 <aotto1968@t-online.de> writes:

> I write a PHP extension and I have the problem that "extern char**
> environ" is NULL → this was probably done in PHP but I don't find the
> position ???

Even if you could find where, I doubt you could change it.

> The funny thing is that "getenv" return the environment variable like
> "PHPRC" but "environ" itself is NULL.

Well that's not so very odd since getenv is the "proper" way to access a
process's environment. Providing access via a global variable is
problematic, and never made it into standard C.

> If I start a subprocess from my extension like:
> → posix_spawn(&pid, path, NULL, &sa, (char *const *) argv, environ)..
>
> The new process get EMPTY environment and will probably NOT work
> correctly.

Yup. You will need to set up the environment you want for the spawned
process. It's probably going to be tedious to do that unless the PHP
extension system provides some method to simplify the task.

> now my question:
>
> 1) if "getenv" work correctly but "environ" is NULL there have to be
> an internal "environ" used by "getenv" and invisible by me.

Yes, that seems very likely to be the case.

> 2) it is possible to access the "hidden" internal "environ" to start
> my process ?

If there is, I don't know it, but you won't find many PHP extension
experts here. Not sure where you might find them. Have you tried
comp.lang.php?

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> aotto1968 <aotto1968@t-online.de> writes:
[...]
>> The funny thing is that "getenv" return the environment variable like
>> "PHPRC" but "environ" itself is NULL.
>
> Well that's not so very odd since getenv is the "proper" way to access a
> process's environment. Providing access via a global variable is
> problematic, and never made it into standard C.

True, but getenv() doesn't provide a way to determine which environment
variables have been set. Either the optional `char **environ` parameter
to main or the `environ` external variable does provide that
functionality.

It would have nice to standardize a function in <stdlib.h> that would
let a program query the full list of environment variables and their
values.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

In article <ths94f$7idc$1@dont-email.me>,
aotto1968 <aotto1968@t-online.de> wrote:
>the PHP extension is a shared library no main :-)
>
> my question was more about the background of "environ" and why "getenv"
>return a value if environ is NULL.

Well, it sounds like, for one reason or another, the global variable
"environ" is getting trashed (i.e., set to NULL). I assume that getenv()
has some other copy of this variable stashed away somewhere, and it uses
that (so it doesn't care about the value of "environ"). You could test
this by setting up some block of environment-like strings yourself, setting
"environ" to point to that, and then see if getenv() works on your new
block or if it still uses the "real" environment. My guess is the later
will turn out to be the case.

Anyway, as I say, it sounds like "environ" is getting trashed. Presumably,
by PHP. Probably intentionally - for "security" reasons - but possibly it
is a bug/unintentional. You might want to consider that, if it *is* being
done intentionally, there might be a good reason for it, and it might not
be advisable to try to end-around it. I'm assuming that this is all being
run out of some web server stack, so you might want think about whether it
is a good idea at all to be running another program from there.

That said, I am going to show you a method that will probably work, if you
want to go that route. This method is, of course, totally outside the C
standard, not guaranteed to work at all, completely on your own, etc, etc.
It seems to work OK with gcc under Linux; beyond that, you're on your own.

Consider this program:

--- Cut Here ---
/* This program demonstrates a method for getting and displaying the
* environment variables (all of them!) without using any of the usual
* variables - argc, argv, or environ. It depends on the (almost)
* undocumented global variable "program_invocation_name", which is,
* essentially, a copy of the usual argv[0].
*/
#include <stdio.h>
#include <string.h>

int main(void)
{ extern char *program_invocation_name;
char *p = program_invocation_name;
int i = 0, eflag = 0;

puts("Argv vars...");
while (1) {
printf("%d) = %p -> '%s'\n",i++,p,p);
p += strlen(p) + 1;
if (strchr(p,'=') && !eflag) {
puts("Env vars...");
i = 0;
eflag = 1;
}
if (!strchr(p,'=') && eflag) break;
}
return 0;
} --- Cut Here ---

So, this method gets you all of the addresses of the program's environment
variables. I leave it as an exercise for the reader to build up a block of
these addresses and pass the address of that block to posix_spawn().

Two other notes:
1) You might be able to trawl around in memory and find the original
environ block (what the "environ" variable pointed at before it got
trashed). This avoids the need to build up one of your own.
2) You might want to consider some other method of spawning a new
process (other than posix_spawn()) that doesn't require an explicit pointer
to the environment. I.e., the usual fork()/exec() stuff.

--
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof.

- John Kenneth Galbraith -

On 08.10.22 22:32, Ben Bacarisse wrote:
> aotto1968 <aotto1968@t-online.de> writes:
>
>> I write a PHP extension and I have the problem that "extern char**
>> environ" is NULL → this was probably done in PHP but I don't find the
>> position ???
>
> Even if you could find where, I doubt you could change it.
>

I just find a "work-around" to put the PHP-internal-hidden-environ into public, so that
I can just do "environ = hidden_environ" at startup of my extension to give "spawn" a proper
environment.

I understand that this is an "unofficial" patch to PHP and a security hole for a "public" web-space

mfg

This is quite interesting and it works

On 09.10.22 11:35, Kenny McCormack wrote:
> In article <ths94f$7idc$1@dont-email.me>,
> aotto1968 <aotto1968@t-online.de> wrote:
>> the PHP extension is a shared library no main :-)
>>
>> my question was more about the background of "environ" and why "getenv"
>> return a value if environ is NULL.
>
> Well, it sounds like, for one reason or another, the global variable
> "environ" is getting trashed (i.e., set to NULL). I assume that getenv()
> has some other copy of this variable stashed away somewhere, and it uses
> that (so it doesn't care about the value of "environ"). You could test
> this by setting up some block of environment-like strings yourself, setting
> "environ" to point to that, and then see if getenv() works on your new
> block or if it still uses the "real" environment. My guess is the later
> will turn out to be the case.
>
> Anyway, as I say, it sounds like "environ" is getting trashed. Presumably,
> by PHP. Probably intentionally - for "security" reasons - but possibly it
> is a bug/unintentional. You might want to consider that, if it *is* being
> done intentionally, there might be a good reason for it, and it might not
> be advisable to try to end-around it. I'm assuming that this is all being
> run out of some web server stack, so you might want think about whether it
> is a good idea at all to be running another program from there.

my extension does not necessary run in an security problem area like a webserver,
it uses PHP as normal programming language like C# C++ Python etc

>
> That said, I am going to show you a method that will probably work, if you
> want to go that route. This method is, of course, totally outside the C
> standard, not guaranteed to work at all, completely on your own, etc, etc.
> It seems to work OK with gcc under Linux; beyond that, you're on your own.
>
> Consider this program:
>
> --- Cut Here ---
> /* This program demonstrates a method for getting and displaying the
> * environment variables (all of them!) without using any of the usual
> * variables - argc, argv, or environ. It depends on the (almost)
> * undocumented global variable "program_invocation_name", which is,
> * essentially, a copy of the usual argv[0].
> */
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> extern char *program_invocation_name;
> char *p = program_invocation_name;
> int i = 0, eflag = 0;
>
> puts("Argv vars...");
> while (1) {
> printf("%d) = %p -> '%s'\n",i++,p,p);
> p += strlen(p) + 1;
> if (strchr(p,'=') && !eflag) {
> puts("Env vars...");
> i = 0;
> eflag = 1;
> }
> if (!strchr(p,'=') && eflag) break;
> }
> return 0;
> }
> --- Cut Here ---
>
> So, this method gets you all of the addresses of the program's environment
> variables. I leave it as an exercise for the reader to build up a block of
> these addresses and pass the address of that block to posix_spawn().
>
> Two other notes:
> 1) You might be able to trawl around in memory and find the original
> environ block (what the "environ" variable pointed at before it got
> trashed). This avoids the need to build up one of your own.
> 2) You might want to consider some other method of spawning a new
> process (other than posix_spawn()) that doesn't require an explicit pointer
> to the environment. I.e., the usual fork()/exec() stuff.
>