Re: popen from cgi program

[Jordon]

> 
> I think i tracked it down.  I have the ‘what’, just not the ‘why’.  My 
> program that i am calling in the popen() call looks for a local config file.  
> It builds the path to it with a call to std::getenv(“HOME”).  This getenv() 
> call is what is causing the segfault.  Why would this be a problem, and what 
> checks can i put around it to avoid calling it in a cgi environment?

Nevermind - i found my derp.  I was putting the return from the getenv() call 
straight into a std::string, which doesnt take too kindly to receiving null!

Re: popen from cgi program

[Jordon]

> Heh. I was poking around with ktrace last night, though you have a much more 
> elegant way of using it.
> I have run my program in the chroot from the command line like you suggest - 
> it works fine there.
> In the cgi program, it blows up after a bunch of mprotect and kbind calls.  I 
> do see a .core file mentioned but i cannot find it, so the cgi part must be 
> swallowing it.
> I made a simple little c++ program that does the popen like i am and it works 
> fine there.  It must be something in the cgi environment - permissions, 
> perhaps?  Or are there some other environmental limitations?

I think i tracked it down.  I have the ‘what’, just not the ‘why’.  My program 
that i am calling in the popen() call looks for a local config file.  It builds 
the path to it with a call to std::getenv(“HOME”).  This getenv() call is what 
is causing the segfault.  Why would this be a problem, and what checks can i 
put around it to avoid calling it in a cgi environment?

Re: popen from cgi program

[Jordon]

> Tips:
> 
> - run it from the command line (chroot /var/www /cgi-bin/whatever), watch
> for error messages in the output
> 
> - run it under ktrace (if this was running from slowcgi, something like
> "ktrace -i -p `pgrep slowcgi`", then try to call it, then ktrace -C),
> you may find some clue in the output from kdump

Heh. I was poking around with ktrace last night, though you have a much more 
elegant way of using it.
I have run my program in the chroot from the command line like you suggest - it 
works fine there.
In the cgi program, it blows up after a bunch of mprotect and kbind calls.  I 
do see a .core file mentioned but i cannot find it, so the cgi part must be 
swallowing it.
I made a simple little c++ program that does the popen like i am and it works 
fine there.  It must be something in the cgi environment - permissions, 
perhaps?  Or are there some other environmental limitations?

Re: popen from cgi program

[Stuart Henderson]

On 2018/01/21 20:00, Jordon wrote:
> 
> > Bingo!  I copied all the necessary libs to corresponding usr/lib dirs and 
> > got the chrooted programs to run from a chroot command, but they would 
> > still not work from the cgi program.  You pointing out that popen requires 
> > sh got me thinking.  Sh was already in /var/www/bin but it had 000 for 
> > perms.  I make it 111 and it works now!  Thanks!
> 
> Looks like I spoke too soon.  The uname and all required libs that i copied 
> into the chroot is working fine.  The ping (that was already there) and my 
> homemade program both work fine when manually executed in the chroot, but do 
> nothing when run through popen().  How do you even debug this?

Tips:

- run it from the command line (chroot /var/www /cgi-bin/whatever), watch
for error messages in the output

- run it under ktrace (if this was running from slowcgi, something like
"ktrace -i -p `pgrep slowcgi`", then try to call it, then ktrace -C),
you may find some clue in the output from kdump

Re: popen from cgi program

[Jordon]

> Bingo!  I copied all the necessary libs to corresponding usr/lib dirs and got 
> the chrooted programs to run from a chroot command, but they would still not 
> work from the cgi program.  You pointing out that popen requires sh got me 
> thinking.  Sh was already in /var/www/bin but it had 000 for perms.  I make 
> it 111 and it works now!  Thanks!

Looks like I spoke too soon.  The uname and all required libs that i copied 
into the chroot is working fine.  The ping (that was already there) and my 
homemade program both work fine when manually executed in the chroot, but do 
nothing when run through popen().  How do you even debug this?

Re: popen from cgi program

[Jordon]

> popen() requires a shell. You are most likely running it in a chroot and
> don't have /bin/sh.

Bingo!  I copied all the necessary libs to corresponding usr/lib dirs and got 
the chrooted programs to run from a chroot command, but they would still not 
work from the cgi program.  You pointing out that popen requires sh got me 
thinking.  Sh was already in /var/www/bin but it had 000 for perms.  I make it 
111 and it works now!  Thanks!

Re: popen from cgi program

[Stuart Henderson]

On 2018-01-20, Jordon  wrote:
> I am still learning cgi/web stuff and stumbled upon an issue.  I am 
> trying to popen() a program to catch what it dumps to stdout.  To start 
> simply, I am just trying to run uname.  I get nothing.  No errors on 
> popen() or pclose(), but nothing printed.  I run the same code from a 
> regular cpp program (changing the khtml_puts() to printf() and it works 
> perfectly.  That makes me wonder if there is something environmental 
> that I am missing, or maybe this is just not allowed.
>
> My code is this:
>
>    char dump[1024];
>    memset(dump, 0, sizeof(dump));
>    FILE *f = popen("uname -a", "r");
>    if(f == NULL) {
>      khtml_puts(, "popen()FAILED!");
>    } else {
>      khtml_puts(, "output: ");
>      while (fgets(dump, sizeof(dump), f) != NULL) {
>    khtml_puts(, "GOTSOMETHING!");
>    khtml_puts(, dump);
>      }
>      int status = pclose(f);
>      if(status==-1) {
>    khtml_puts(, "pclose()FAILED");
>      }
>    }
>    khtml_puts(, "done");
>
>
> All I get from it is "output: done"
>
>
>
> Also, my httpd.conf is this:
>
> ext_addr="egress"
> prefork 2
> server "localhost" {
>      listen on $ext_addr port 80
>      root "/htdocs"
>      location "/cgi-bin/*" {
>      fastcgi
>      root "/"
>      }
> }
>
> Any ideas?
>
>

popen() requires a shell. You are most likely running it in a chroot and
don't have /bin/sh.