Are WebEnabled Environment Permissions too relaxed since I can browse a large portion of the directory structure?

A question regarding permissions on the WebEnabled filesystem came from one of our users as follows:

I connected via SSH with the credentials for my application vhost and it loaded up in the root folder, which gave me access to your entire server. I browsed for a bit to see that I was indeed in the main server with other sites in it, I didn't have access to other peoples sites, but I had full access to browse your server. I tried to change a file to see if i had access to that, but wasn't able to!

I just wanted to let you know, I'm not that way inclined to do anything unsavory, I love your service, but a baneful person with a bit more know how might be able to do some damage!

The short answer is that what you saw was as intended. Yes, we're providing greater access to our WebEnabled environments than what some of our users expect to see, whereas other users actually expect and often even require this level of access.

To the best of our knowledge, we have proper directory and file permissions in place. In fact, you did mention you were unable to modify a file that was not yours, and you were unable to access directory sub-trees belonging to other users.

Restricting SSH access to a sub-tree would not improve our systems' security, because PHP scripts uploaded by the users may need to access system libraries and the like. Additionally, SSH access is there not just to enable a user to work on their own files, but also to run programs on the server - e.g., the command-line PHP or Perl interpreters or the C compiler. Thus, restricting it to a sub-tree would reduce it to file upload/download access, which would be far too limited for many intended uses of the WebEnabled platform.

Yes, there's certain risk that we accept in providing shell access to our WebEnabled environments, but the risk is justified. There are various security measures in place to mitigate these risks, including the use of a security hardened "Linux userland", the use of OpenVZ containers (what you saw was not exactly "the entire server", but rather a WebEnabled environment running in an OpenVZ container on one of the servers), and remote backups.