If you want to go with a queued solution, consider using rabbitmq with their rpc: http://www.rabbitmq.com/tutorials/tutorial-six-python.html Basically, apache will send a message over the queue and then listen on a new queue for the response.
The example is in python, but the concepts in php are the same. -Eric On Mon, Dec 16, 2013 at 6:36 PM, Walt Haas <[email protected]> wrote: > Good points Brad. Also consider putting Apache in a chroot jail. > > -- Walt > > On 12/16/2013 06:28 PM, Brad Davis wrote: > > Setuid and web sites create the biggest possible place to open security > > holes on a machine, even worse than SQL injection because you can leave > > the whole machine vulnerable. My suggestion (from personal experience) > > is to write a small, well debugged C program that checks all its > > parameters for legality, exiting if anything is wrong before it > > setuid()s to the appropriate user (sometimes root, mostly someone else), > > executes its system call (no, don't make it general to execute > > anything), and exits. The program is stored in a directory that the > > apache can't directly access and is executable only by the web user. > > > > Examples: > > Creating directories: Only allow this to be done in certain > > directories (or a single directory), reject paths, reject paths with > > ".." in them, setuid() to the owner (or the group) of the > > owner of the directory. > > Executing pre-written scripts: Only allow predefined scripts. > > Always use absolute paths to those scripts. Make sure the scripts have > > appropriate permissions (no writeable, no suid), > > don't allow general parameters to the scripts, only > > allow a certain user to execute the script, setuid() to that user. > > Restarting services: Limit to predefined services, check that > > the service really needs restarting, possible check for failures that > > happen too fast. > > Changing ownership or permissions: Predefine what can be done, > > code that into the program, and use a simple parameter choose what can > > be done. > > > > If this is a team project, only one member of the team should work on > > the program, especially when fixing bugs. > > > > Don't leave anything unspecified. Don't allow anything "easy" through. > > > > Brad Davis > > > > > > _______________________________________________ > > > > UPHPU mailing list > > [email protected] > > http://uphpu.org/mailman/listinfo/uphpu > > IRC: #uphpu on irc.freenode.net > > > > > _______________________________________________ > > UPHPU mailing list > [email protected] > http://uphpu.org/mailman/listinfo/uphpu > IRC: #uphpu on irc.freenode.net > _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
