Configurations scopes
First, there is the operating system. The operating system knows and controls users because of security reasons. It should be clear in shared environments, that one user should not be able to attack another one in a harmful matter. Let call me such users a sysUser.
The configuration design ranges from giving no sysUser account until giving a generous one to the Isp's client. The first one is hardy useful, because there is the need to transfer files to the server, and for that a sysUser account is required. There are two questions to answer in this matter: the permissions of that sysUser account and the software and protocols to transfer data to the server.
Second, important to regard, there is also a sysUser assigned to run the webServer. In other words: the webServer runs in an assigned user security context with limited permissions (against the systems admin / root account). But the webServer is yet shared for several sites.
Third, there is the DBserver. No DBserver in the world wants to be touched anonymous. And the DBservers is shared also.
File transfer
Popular software and protocols to transfer data accross the net is FTP. Both, the protocol and the general software to play with that protocol, are named FTP. Some popular OpenSource software for FTP is FileZilla. But (the protocol) FTP is unsecure, because authentication data are transmitted uncrypted. The better choice for transfers are the protocols SFTP and SCP, because authentications (and data) are transmitted encrypted. FileZilla is able to use SFTP, but naturally requires from the server to support SFTP. To support SFTP (and/or SCP) is the Isp's decision. Very too much Isp's in the world do not support SFTP/SCP. It should be a good reason for you to take such Isp's out of your choice.
Whatever, the files you transfer to the server become to belong to your sysUser account; you are the owner of the data. There is at least one sysUser beside yourself with good reasons to access the files just transmitted: that is the webServer. Let assume, the webServer is granted permissions to, at least, reading the data. But, when the webServer is allowed to read the data, is any sysUser else able to do the same? It does not seem so, but easy it may be. That again is a matter of configuration and layout of the operating system the Isp has decided. Let tell, the configuration is not quit easy.
Simple systems
All sysUsers, including the webServer user, are in the colored garden of the whole system. To have some security, the permissions are assigned as good as possible in the filesystem. But the possibilities are very limited and no Isp should decide for. Such a simple system is very pretty for own exclusive usage, but never suitable for multiuser shared environments Isp's offer for webSpaces. The advantage is: ease of configuration, less administration, good performance, less resource needs.
Chrooted systems
To isolate sysUsers and their resources, chroot (a synonym for change root) techiques are one choice. The approach is, to build an isolated environment for each or some sysUsers, that leads to a condition where sysUsers can handle free the permissions without the danger of affecting others. Often you can read about "root jails". That means, your environment seems to be the only one, there is nothing beside or above. In that case, you may treate yourself as a root, the biggest chief in the system. Indead, chrooted environments are a well choice for Isp's. But the configurations are more complex, there are more resources required for the system (because essential data, like binaries, but also like authentication data, are stored several times - redundant). Fact is, an Isp can serve less clients on such a system, the costs - for resources and configurations - are more.
eZine
