On one of my hosts I found this easy to do account breach:

It's a shared account server and anyone who logs on to the shell basically has access to other user's accounts. Just go to the directory where each account's web folder is located and let's say presume there's phpmyadmin there. Cat the config.inc.php file and you get the username and password to their database. You really can't lock out the 'other' read permission because you it has to be read when it gets fetched from apache. But for some files, especially script files (PHP or pl), these files include some sensitive info like database passwords.

Is this a serious security issue?

Its not really a hole.. Its a fact of life :D

It is very serious. You messed up your permission. This has been discussed a lot in the past. Search the forum, you can find a lot of information there.

Actually, I didn't mess up anything. That is how the account dirs are laid out in the server. I'm close to accepting what Prohacker said that there's nothing I can do. Although there might be workarounds, and I'm still figuring that out.

Sorry, I was under impression that you are a web host. There is nothing you can do to fix that completely. The best you can do is to chmod your homedir to something like 751 or 711, this will hide files inside your homedir, but any other user with knowledge of your directory structure can still view any of your files.

As other posters stated, this has been discussed, and in some detail. It's a balance of permissions and ownership. It's also a matter of how you set up/configure the server, not just for shell, but for things such as CGI and web server components as well. With proper ownership and permissions, chroot shells aren't even needed, although they usually don't hurt (although some can open up other security issues) -- it's by far no means of a real solution -- you should be able to be fine with controlling other aspects, like the mail and web server to be in check -- plus you have the advantage of better process control too -- to keep things up and running smoothly.

It's not too detailed, really, but you have to have some general knowledge of how it all works and what/how to do things to make it simple to explain. I would rather not try and repeat some of my long posts I've made about this topic before in regards to shared user hosting environments, but as another poster suggested, you should do a search in these forums and you ought to find a few of these threads. If not, let us know and I might be able to find the specific topic/thread in question by remembering some key words to search for and recognizing the threads' title.

Yes, I'm not a web host so I can only control permissions only to my own directories.

It all comes down to one thing: That's just the way it is. I can 711 the directories but when someone learns your file names (which really isn't hard to do), you can't do anything about it.

This is a general fault with alot of web hosts these days. The solution is rather simply but can be tricky to fix with some intergrated systems.

What needs to be done is the users home directory must be owned by a user and group that no one else has on the server and the correct permissions set so that only the user/group can read/write. On alot of servers the group is e.g. "users", "members"
, etc and that is why you can roam free into other accounts.

Originally posted by virgil
Yes, I'm not a web host so I can only control permissions only to my own directories.

It all comes down to one thing: That's just the way it is. I can 711 the directories but when someone learns your file names (which really isn't hard to do), you can't do anything about it.

Yes, that's my point. Only your host is able to really fix the problem. I think you should inform your host about the problem if you haven't done so.

Yup will definitely give them info on this.

vSector, each account is in a unique group named after the account name. However, not all members remove the other read permissions from their folders.

Yeah its a real bitch. I pointed this out to Cpanel nearly a year ago and no fix was offer, I've since noticed its pretty standard, of course all the web hosting companies that advertise cpanel also advertise their service as secure (lol), its an exploit that a dummy can execute, get php source, grab mysql password, retrieve credit card numbers. There are lame ways to offer security by obsecurity with base_dir, hiding files etc.. but its all the same to someone who knows want they want, they can get it.

Apache 2 will change this with their perchild MPM, in Apache 1 suexec allowed for user switching when executing CGI, however did not support in-context switching for things like mod_perl and mod_php. In Apache 2 the childs are launched under the user ID.
Apache 2 will make shared web hosting very secure, in addition other benefits will come to, since the childs execute mod_php and mod_perl under the actual user it will be easier to track resources between the clients.

its an exploit that a dummy can execute, get php source, grab mysql password, retrieve credit card numbers. I'm not trying to excuse bad directory/file permissions, but anyone who's storing un-encrypted credit card information in a mysql database is just ASKING for problems. ;)

Although a lot of people dislike Ensim, this is one area that it really shines.

Originally posted by Shannon
I'm not trying to excuse bad directory/file permissions, but anyone who's storing un-encrypted credit card information in a mysql database is just ASKING for problems. ;)

I'll go one further and say that anyone who is storing credit card information on their web server is just asking for problems. There was a thread on NANOG recently about how it is possible to build a computer using currents COTS components that could crack a 1024 bit encryption key in a few hours.

So, even enctrypted data is not necessarily safe :D.