Hi, I agree. Sorry that should have been PHPsuexec not PHPexec. It allows scripts to run as the user account they are launch from. So in stead of running as nobody it creates a process for the user account to run php scripts. Some hosts won't use it because on shared hosting it can use more ram since there are has to be a process for each user account running php. On the other hand it makes it easier to see who is running what scripts and who might be hogging processor cycles with a script since they are run as the user account they are launched from.
Sincerely, Mike -- Mike Brandonisio * Web Hosting Tech One Illustration * Internet Marketing tel (630) 759-9283 * e-Commerce [EMAIL PROTECTED] * http://www.jikometrix.net JIKOmetrix - Reliable web hosting On Mar 1, 2006, at 2:37 PM, James Keeline wrote: > --- Mike Brandonisio <[EMAIL PROTECTED]> wrote: > >> Another way it could get there is a user on the same server, meaning >> another hosted web site, could read/write to a file with insecure >> permissions. Some host providers have php run as nobody for all of >> the web sites hosted. Your site is created by the user but may be >> part of the nobody group. Since everyone on the server has content >> that is part of group nobody a script on difference web site on the >> same server could read/write to another web site with insecure >> permissions. Other host providers run php as the user account of the >> web site and thus prevent this cross over. Content on the hosted site >> is owned by the user and part of the users group not nobody. Our >> servers have been secured this way. I think php has to be built with >> phpexec enabled. >> >> Sincerely, >> Mike > > The php.ini configuration open_basedir can restrict a PHP script to > access files in a certain > branch of the filesystem, effectively isolating it from other parts > of the filesystem like a Unix > chroot would for the entire OS. However, I have not seen that it > is possible to implement this on > an Apache virtual host basis. It would be quite useful if this > could be done. > > Similarly, safe_mode restricts PHP scripts to files owned by the > same user as the script itself, > on top of the permission settings. > > I will look into phpexec to see what it does. I've not seen it > before. > > Any time the webserver user (whether it's "nobody", "apache", or > something else) is allowed to > write to a file or directory in the web space, trouble can occur, > especially on a shared system as > you observe. These sort of permissions are sometimes set to allow > file uploads or to let PHP > write to text files, etc. It is risky. > > Some packages include this sort of functionality and file or > directory permissions. I would not > be surprised if the people whose servers have been attacked in this > way have something in common > in the form of a common third-party PHP application or at least a > similar technique. > > With PHP being so popular, a cron-job to scan for risky > permissions, code, etc. could be a useful > tool for webhosts. It seems unlikely that something doesn't > exist. Or, perhaps people just roll > their own or don't want to keep up with it or accept responsibility > if it misses something. > > James > > > > Community email addresses: > Post message: php-list@yahoogroups.com > Subscribe: [EMAIL PROTECTED] > Unsubscribe: [EMAIL PROTECTED] > List owner: [EMAIL PROTECTED] > > Shortcut URL to this page: > http://groups.yahoo.com/group/php-list > Yahoo! Groups Links > > > > > > > > > Community email addresses: Post message: php-list@yahoogroups.com Subscribe: [EMAIL PROTECTED] Unsubscribe: [EMAIL PROTECTED] List owner: [EMAIL PROTECTED] Shortcut URL to this page: http://groups.yahoo.com/group/php-list Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/php-list/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
