NYCPHP Meetup

[Hans Zaunere]

> > I've thought of three ways to do it: 1) have the sysadmin create a sudo
> > user that can run the given commands with no password, 2) create a
> > sudo user and store his name and password outside of the document root,
> > or 3) write some C wrappers and set them suid. I'm not crazy about any
> > of these solutions.
> 
> When faced with these options, I would choose #1.

The simplest and most straight forward would probably be number 1 or 2 - but then don't forget that sudo is basically like giving them root for that command.  If that command can modify, the sudo can too.

3) is probably the safest if written well, but then there lies the trick :)  For complex root operations, like filesystem stuff, I hand commands off to a very simple and carefully written daemon that runs as root.  The daemon only accepts very specific commands and responds accodringly.  This is actually similar to option 3, except that the apache process is "further" away from the infamous UID 0 in many ways.

> > Anybody else have a better idea?
> 
> Well back in the old days I would copy the binaries required (when
> possible) to a separate path for the httpd/apache user, but I was
> always very careful to restrict what the apache user could do.
> 
> Your OS on the server may also provide some extra protection (chroot
> jails etc.). I'm definitely interested to see what everyone else would
> do in this situation.

Since the scope of root operations needed in this case seem limited, I'd avoid root all together.  How about a cronjob that dumps the info you need to a database, or even a file?  Or a queue system, where jobs are queued by apache, and a cronjob wakes up every so often to fill the queue with a response?  There might be some delay, but depending on the load you expect, it might be insignificant.


---
Hans Zaunere
President, Founder

New York PHP
http://www.nyphp.org

AMP Technology
Supporting Apache, MySQL and PHP