Re: CGI apps in C?



On Sun, Jul 16, 2006 at 06:19:35PM -0400, Mark Bucciarelli wrote:
"fork a shell"

This would be used if you want to run "find" or some other shell
utility from your C code. Correct?

Yes, if you call system(), or popen(), or something else which invokes a
command via a shell.

If you explictly fork() and in the child do
execl("/usr/bin/find",arg1,arg2...) then you don't have this problem, as
you're running the program directly.

Silly example: don't write things like

snprintf(buf, sizeof(buf), "rm /tmp/sessions/%s", sessionid);
system(str);

when the user could present a sessionid of

../../etc/passwd

or worse something like

1234;echo "foobar"|passwd root

Yes, I did a bunch of reading when setting up my first FreeBSD
server and settled on running PHP apps using fastcgi + suexec.
Very RAM-heavy, as each client get's their own php interpreter
resident. They time out pretty fast, which is good for RAM but
bad for the next time someone visits the site. There is no
better solution I have found for performance + security with PHP.
And I don't like it much ... hence my initial post.

Well, the Unix security model is that once a process has switched to user id
X, it cannot switch to another userid (at least not unless it exec's a
setuid binary and hence becomes a new program). That's the basis of the
security model; if you assume that an attacker comes across a process
running as X where they can substitute their own code, there should be no
way they can switch to user Y.

So if you have 1000 users, then either you need 1000 processes floating
around, each running as one of those userids, or you need to start a new
process for each request.

In the limiting case, you could run 1000 webservers under different uids
listening on different ports, and have a front-end webserver answering on
port 80 and relaying the requests to those other servers (e.g. using
mod_proxy under Apache). It will eat RAM, but perhaps not as much as you
might expect due to shared code pages (especially for those sites which
don't have mod_php and the like loaded)

Since in my experience the vast number of websites are either (a) idle, or
(b) completely static content, then having a split where the majority of
sites run on a single process with suexec for the odd CGI request, and a
small number of "premium" servers where each user has their own httpd server
process, seems to make sense. Each user can then customise their config,
e.g. those who want mod_perl or mod_ruby can have it.

Of course, "super premium" customers can have their own operating system
too, running under Xen or VMware :-)

Another thing I did was to modify suexec so
that it would fork(), wait4(), and then log the rusage
information for each CGI execution. Analysing these logs lets
you work out, site by site, which are the CGI hogs.

That sounds pretty interesting. Did you publish your work?

Unfortunately not - it belongs to my ex-employer. However I did suggest that
this functionality could easily be included in mod_cgi, with an outline
patch you might be able to use here:

http://mail-archives.apache.org/mod_mbox/httpd-dev/200512.mbox/%3C20051205091812.GA90189@xxxxxxxxxxxxxx%3E
(point 2)

You replace the existing wait/waitpid call with wait4(). It's more efficient
to do it there anyway. In our case it was more important to avoid touching
the base code, which is why I moved this into suexec, which we had to
customise for other reasons anyway.

A quick google search suggests that maybe cgiwrap can do this:

http://cgiwrap.sourceforge.net/changes.html
"New in version 3.6.2:
...
* Added support for reporting rusage/return code after executing script."

But I've not used cgiwrap myself.

Regards,

Brian.
_______________________________________________
freebsd-isp@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • CGI not novel, instant CAI gratification is garbage (was: JDEE/CGI/flashcards ...)
    ... CGI is just an interface to run ... network to the server, the application processes the ... Google Groups had a simple tree view that for really large threads ...
    (comp.lang.lisp)
  • How Hackers Attack Web Servers, CGIs, PHP, ASP, etc.
    ... Web Site Hacking - General & Miscellaneous ... NetWare Enterprise Web Server - two issues ... SITEWare cleartext passwords, read arbitrary files ... Web Site Hacking - CGI, Perl, ASP, PHP etc. ...
    (soc.culture.indonesia)
  • Re: Hard or Easy? To find string, then grab criterion matched lines above and below?
    ... There is no cgi or Web Server involved in ... I didn't know "cgi was off limits" or taboo in this ... he conditionally pulls data from FILE-A and uses this data to ... So please tell me how anything he said can be seen as a CGI question, ...
    (comp.lang.perl.misc)
  • [ANN] acgi-0.1.0
    ... no special webserver setup or system privledges required ... a acgi application consists of a cgi server backend which loops, ... incoming requests; the requests are delegated to this backend server via a ...
    (comp.lang.ruby)
  • Re: arrange form data in same order as on form
    ... > CGI invocation need in comparison? ... mod_perl is of course suitable in order to further reduce the server ... would allow 5 times when only the Perl part is taken into account. ... > need no advice from me. ...
    (comp.lang.perl.misc)