On Mon, 2002-05-13 at 09:54, Ilia A. wrote: > > Now you are really starting to stretch it. I am sure the ratio of > > customers that have db backends are much smaller than general webhosting > > customers > > PHP is very commonly used with a database (MySQL). I'd venture to say that 70% > of people who actively use PHP use it with MySQL or another database system.
You are probably correct about that. > > > > In all of these scenarios, the webserver itself would just spawn another > > process, and the os would page the other one because it is not in use, > > and then eventually the webserver would log the problem. > > > > If you factor that in with a shared environment with multiple webservers > > and a load balance, your risk is pretty low. Even if someone did do > > something like that to kill all of your webservers, you would easily be > > able to find out who did it, and fix the abuser. > > You could track down the abusee easily, simply using Apache's server-status to > see what each process is doing. But if you are tracking down the abuser you > are already too late because the problem had already occured and now you are > doing damage control. Sure you remove this user, but what about the next one? > > > how are you planning on protecting your passwd file then? > > Simple, use the file permissions to prevent the webserver from accessing it. > Or put the webserver inside a chroot jail, so it cannot even see parts of the > OS. > All processes have to have access to /etc/passwd. Try disabling access to it, everything will break because all uid calls will fail I was pointing out that OS permissions can not fix the problem. Yes, you can perform a chroot(), however then you have to use php as a cgi which kills performance. Though wrapping a fastcgi interpreter with suexec might be a much better solution.When you do build a chroot area you have to put a bogus /etc/passwd. Both open_basedir and safe_mode protect /etc/passwd. (Well for safe_mode, after the show_source() vulnerability you found was fixed. However open_basedir still would have prevented that) > > > > > If you have sensetive data, like credit card information and you are not > > > using a dedicated server to store that data then do be surprised to find > > > your data in someone elses hands. In a shared enviroment especially where > > > programming/scripting languages are avaliable it is merely a matter of > > > time before someone takes advantage of some security hole/oversight and > > > grabs the hold of your data. > > > > So then you are agreeing : ) > > If your making a point about people with sensetive data needing their own > servers, then yes, I whole heartedly agree with you. > > > Or you could try something more useful, like fixing a bug in safe mode, > > adding a new security feature, etc. etc. However, I suppose it is too > > difficult to come up with a constructive solution. > > I believe fixing bug in safe_mode is a pointless process because new ones will > appear instantly. Safe mode bugs have been fixed in every release since it > was first introduced and we still have problem. > > > Hmm, but you just said that a shared webhosting enviroment, by nature, > > has no real safety. > > It doesn't. > > > > > Pointlesly difficult..... > > then safe mode must be doing something.... > > Yeah it is, making development a little slower because you need to make > safe_mode work arounds. Yes that is unfortunate that restrictions can make development more difficult. > Ilia > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
