Date: Tue, 18 Jul 2006 13:45:58 +0100 From: Brian Candler <B.Candler@pobox.com> To: Mark Bucciarelli <mark@gaiahost.coop> Cc: freebsd-isp@freebsd.org Subject: Re: CGI apps in C? Message-ID: <20060718124558.GA26642@uk.tiscali.com> In-Reply-To: <20060716221935.GA3600@rabbit> References: <20060714195603.GE396@rabbit> <fe77c96b0607141303l7430059fi19cac79a2e97d094@mail.gmail.com> <20060714202233.GF396@rabbit> <20060715181054.GA15489@uk.tiscali.com> <20060716221935.GA3600@rabbit>
next in thread | previous in thread | raw e-mail | index | archive | help
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@uk.tiscali.com%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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060718124558.GA26642>