[nycphp-talk] system commands and backups
Mark Armendariz
nyphp at enobrev.com
Tue Mar 4 20:05:43 EST 2003
Actaully, the security concerns you're mentioning is the primary reason
for my shout to the group. I really want to offer a good solution, but
it seems like it leaves a pretty wide hole open.
Anyone else know of ways to run special user privileged commands with
half the fat?
Thanks George.
Mark
> -----Original Message-----
> From: George Webb [mailto:gw.nyphp at gwprogramming.com]
> Sent: Tuesday, March 04, 2003 7:50 PM
> To: NYPHP Talk
> Subject: Re: [nycphp-talk] system commands and backups
>
>
> > Is there a way to allow a php script to run
> > shell commands as an admin or specific user?
>
> Hi Mark. I have done this, but before anyone would want
> to do so, they should recognize the security risks involved.
> It may be a convenience versus security issue, wherein you
> may accidentally allow all of your web users (possibly
> everyone in the world?) to access anything that your user
> (or worse yet, your 'root' user) can.
>
> So I hope you already know all about that. Now,
> to answer your question, you may be able to set the "setuid"
> bit on your PHP CGI executable, together with changing the
> ownership of the executable itself. Then you can associate
> certain files or directories to use *this* PHP CGI handler
> instead of the default (apache module PHP, correct?).
>
> For example, if you want all files ending in '.uphp'
> to be executed by your special set-user PHP, you might do the
> following, which will allow *.php files to be executed
> normally, but *.uphp files will be executed by user 'marka'
> (or whatever):
>
> 1/ Add the following Apache .htaccess lines:
>
> Options +ExecCGI
> AddType cgi-script .cgi
> Action user-php /php.cgi
> AddHandler user-php .uphp
>
> 2/ Copy your PHP 4.3.1 or later CGI binary to
> your webserver root, and rename it as described above (php.cgi).
>
> 3/ Change the ownership as appropriate, and
> set the setuid bit:
>
> chown marka php.cgi
> chmod u+s php.cgi
>
> 4/ Sit back and wait to be hacked!
>
>
> One other nice thing is that this PHP parser can
> have its own php.ini file, which may be different from the
> one the rest of the webserver uses!
>
> Maybe some other better sysadmins can comment on
> how to make this setup more secure. Like these ideas:
>
> 1/ Run a separate httpd server on a special port
> using this special configuration.
>
> 2/ Restrict the special port using a firewall or
> ipchains or whathaveyou.
>
> 3/ chroot the filesystem for this special config,
> so that your whole machine won't get hacked.
>
>
> Another approach (which maybe I should have mentioned
> first) is to use 'sudo' to allow your 'nobody' user to do
> only certain special tasks.
>
> If your webserver is on a totally private network and
> you're not worried about system security, you can do a lot
> more. But if it's on the Internet, be aware!!!
>
> Best, George.
>
>
> George Webb
> gw.nyphp at gwprogramming.com
>
>
> --- Unsubscribe at http://nyphp.org/list/ ---
>
>
>
>
>
More information about the talk
mailing list