Changes

Instead As said, you can waste hours of wasting time to secure in securing all the possible things you don't want as a webhoster and in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you pronbably miss dozens of alternative routes. In this process you frustrate your clients, it because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far betterthe most effective method. Instead of the above route, we take a different approach. The main problem is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, easier you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more flexible to than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every account user its own environment. OpenVZ is ideal for thisminimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.