Shared Hosting Permissions

Hi,

I have a client on shared hosting with a small hosting firm. I can access all of the accounts on the server! I could delete or hack all of the other websites on the account. When I tell the host that this needs fixing they say…

We run a standard UNIX Apache server; access is decided on a per-file basis by the filesystem. Each website user is capable of determining what level of security access they wish to grant to their files; if they do not wish others to be able to access their files, they are able to do this.

Our Apache servers use suExec and suPHP. This allows each website’s
scripts to be executed by the user who owns the files. Thus, script
files only need to be readable by the website owner because the CGI or PHP process will be running as that website’s user, and any sensitive scripting files (e.g. files with database credentials) do not need to be world or group readable. Web devs are free to change the permissions on their files as they see fit. I would generally recommend that PHP configuration files containing login credentials be so secured.

To elaborate, there are two contexts under which a website’s files
are accessed. First, is by the webserver. The webserver typically
runs under an unprivileged account (on our servers, it’s the ‘www’
account). The webserver needs to be able to read HTML, graphics
files, zip files etc. to be able to serve them over the web. Such
files, therefore, must be world readable. Since they’re meant for
public consumption, there are also no security concerns with making
them world readable.

The second context is scripts, either CGI or PHP based. On Vinyl3,
both are executed under the website user’s own context, via suExec for CGI files and suPHP for PHP scripts. This means that the user needs to be able to read the files, but no one else need do so.

So we have a choice: by default files may be either world readable
or not. If we choose world readable, then everything works, and web
devs may modify their scripts’ permissions to restrict world access
should they choose to do so.

If we make the default *not* world readable, then web devs would
need to modify the permissions of all their simple HTML, graphics,
and so on files before they can be served over the web. I shudder
to think of the tech support calls we’d get if we attempted this.

One-size does *not* fit all. The current configuration lets
everything work out-of-the-box, while allowing those wishing or
requiring greater security to make use of it.

In other words, if you can read a file on the server, it’s because the file must be public so that Apache can serve it, or because web
developers do not care about the files’ security have set their files’ permissions such that any may read (but usually not write) them.

Please let me know if you have any other questions.

and…..

Please note that Vinyl3 is a shared server environment which provides full shell access (which, by the way, means chroot’ing is useless– or,at best, an illusion).

Note that a typical shared server does *not* run suPHP. This means that most PHP code running with a standard mod_php setup is run under the webserver’s context (i.e. user “www”, as above). Since all code run by PHP must thus be accessible to the Apache user, it naturally follows that anyone who can run PHP code on the server can automatically read anyone else’s PHP on the same server.

This, of course, means that PHP code is inherently insecure in the
most common configuration for a shared server. It’s why we embraced
suPHP when it became a reasonable option for a production PHP
server. At last PHP code could be run securely in the user’s own
context. If a web dev didn’t want the world reading a certain PHP file (usually a config file), then they could make it so.

Understanding file permissions is fundamental skill that every webmaster should know. Having said that, we understand that not everyone will know the basics.

Permissions are managed in three distinct classes. These classes are
known as user, group, and others. On Vinyl3 scripts like PHP and cgi are run under the user, this means that only the user needs to be able to read those files. Simply removing read permissions from others on the files you do not want world readable will do the trick.

On Vinyl3 you have the tools to make your PHP and CGI files absolutely secure, should you wish to do so. This is not true on many or most shared PHP servers.

Please let me know if you have any other questions.

What I take from all this is that they are saying it’s up to the individual site owners to set permissions to keep others out. BUT on all other hosts I’ve never been able to go up folder levels beyond the site I logged in with! I’ve told the client to change hosts but he wants to sort this out with them. Is this something I can fix with folder permissions without breaking WordPress?