Results 1 to 25 of 52
-
05-15-2005, 04:30 AM #1Newbie
- Join Date
- May 2005
- Posts
- 11
look ma, i can see everyone's shared account!
I just signed up with a hosting co. that gets consistent rave reviews. but when i logged in via ftp, i realized I could jump back one directory and view everyone's account. i counted about 80 or so.
thinking this was some major security hole, i contacted customer support and they said that is the way the server is set up and that is a normal arrangement for shared hosting. He said he could set permissions so that other could not see my directory on the server.
Is this a "normal arrangement"? Does anyone out there have a similar situation where they can see all of their "friends" on the server?
thanks,
takayuki
-
05-15-2005, 04:42 AM #2I am a newbie :D
- Join Date
- Jun 2004
- Location
- Internet
- Posts
- 1,805
I dont think this is normal. This is a big issue where your privacy is at stake.
When you log in through FTP, are you only able to see other accounts or you have rights to modify files as well.
Would like to know host's name. If you can.<<snipped>><<snipped>>
why?
-
05-15-2005, 04:48 AM #3learning is in the doing
- Join Date
- Sep 2000
- Location
- Alberta, Canada
- Posts
- 3,146
What Control Panel is being used?
• PotentProducts.com - for all your Hosting needs
• Helping people Host, Create and Maintain their Web Site
• ServerAdmin Services also available
-
05-15-2005, 04:48 AM #4Newbie
- Join Date
- May 2005
- Posts
- 11
Their policy was "you can look, but not touch..." So you could not modify files. And I suppose this is reasonable b/c you can grab anyone's source code. But what if I had a setup.php file with passwords on it?
I'm not a sys admin. I'm a web designer who knows a little php, etc., and just enough about linux/unix to get by.
I don't want to smear that company on the forums here b/c they were great otherwise. I just others' opinions whether this is normal.
thanks
-
05-15-2005, 04:57 AM #5learning is in the doing
- Join Date
- Sep 2000
- Location
- Alberta, Canada
- Posts
- 3,146
I take it the CP is WHM/Cpanel?
• PotentProducts.com - for all your Hosting needs
• Helping people Host, Create and Maintain their Web Site
• ServerAdmin Services also available
-
05-15-2005, 05:01 AM #6Web Hosting Guru
- Join Date
- Jan 2005
- Posts
- 319
If its Windows, then the hosting provider needs to correct the permissions.
Knowing too much information can lead to big hacking.
-
05-15-2005, 05:22 AM #7Web Hosting Master
- Join Date
- Dec 2004
- Location
- San Francisco, CA
- Posts
- 1,912
If I remember correctly, one user of Pair.com reported they could see other customer directories and browse them, but not modify or download anything.
If that is the case, I think it'd be fine but personally I wouldn't have my own servers setup that wayinit.me - Build, Share & Embed
JodoHost.com - Windows VPS Hosting, ASP.NET and SQL Server Hosting
8th year in Business, 200+ Servers. Microsoft Gold Certified Partner
-
05-15-2005, 06:08 AM #8Newbie
- Join Date
- May 2005
- Posts
- 11
Thanks for your comments.
They use linux and the CP is called the "Account Control Center". Not cPanel.
I want to go with this company b/c I think the support is good and everyone I've spoken to says they are top notch.
Should I worry about being able to view others' files? I'll request they "hide" my directory via permissions.
takayuki
-
05-15-2005, 07:05 AM #9Newbie
- Join Date
- Apr 2004
- Posts
- 27
For all database driven sites, the passwords for the DB's must be in some file, so this setup means you will probably be able to find most passwords to the databases of other users...
Of course this is a big security problem. Not only if there should be a malicious 'customer', but also if only one of the customers is not very careful with his password or if one account is hacked, so I should definitely worry about this setup.
It should be very easy for the host to setup FTP in such a way that everyone sees his own directory as root.
-
05-15-2005, 07:27 AM #10Retired Moderator
- Join Date
- Aug 2003
- Location
- PA
- Posts
- 1,914
Of course this is a big security problem.
Just a little bit of insight on this topic. I would say anything where you have critical passwords definitely belongs as 700 or 750 always be sure global/world has no access.
-Justin
-
05-15-2005, 07:28 AM #11Web Hosting Master
- Join Date
- Jun 2001
- Posts
- 747
-
05-15-2005, 08:11 AM #12Newbie
- Join Date
- Apr 2004
- Posts
- 27
Originally posted by jschurawlow
Easiest way for a client to stop people from probing your orifices so to speak would be to chmod your files to 700 or 600 depending on what types of scripts they are of course. This should work fine provided apache is setup to spawn into your uid when accessing your website vhosts in the apache configuration.
Just a little bit of insight on this topic. I would say anything where you have critical passwords definitely belongs as 700 or 750 always be sure global/world has no access.
-Justin
It might be enough to chmod your files to e.g. 604. In most cases, other users on the same server will not have access to your files while the webserver can read them... it depends however on the setup of some things.
-
05-15-2005, 08:11 AM #13Newbie
- Join Date
- May 2005
- Posts
- 11
someone asked who the host is. it's pair.com.
anyone hosted with pair want to chime in?
-
05-15-2005, 09:39 AM #14Aspiring Evangelist
- Join Date
- Jan 2002
- Posts
- 428
Originally posted by takayuki
someone asked who the host is. it's pair.com.
anyone hosted with pair want to chime in?
-
05-15-2005, 10:08 AM #15Newbie
- Join Date
- May 2005
- Posts
- 11
any problems with pair?
why did you leave?
-
05-15-2005, 10:11 AM #16Newbie
- Join Date
- Apr 2004
- Posts
- 27
I looked at the website of pair.com and they have information about this in their knowledgebase. Indeed, as I suspected, the webserver runs as user 'nobody' with limited access. If you chmod your files to 604, (or 705 if execute permission is needed) you will be able to read and write the file and the webserver can read it, but other users can not directly read it***, if you need to give also write access to the webserver you need to change permissions to 606 (or 707 for execute permission).
*** Notice however, that any file that can be read or written by the webserver, can be (indirectly) also read and written by other users if they write a simple script for it that is executed by the webserver, e.g. with a php command 'readfile'.
-
05-15-2005, 10:12 AM #17Web Hosting Master
- Join Date
- Feb 2004
- Posts
- 2,197
Thats a bit insecure, in a shared hosting environment FTP accounts should be chrooted to their home directory...
crucialparadigm - Affordable, Reliable, Professional :
Web Hosting
• 24/7 Support • Web Hosting • Reseller Hosting • Cloud/VPS Plans • Dedicated Servers •
-
05-15-2005, 10:28 AM #18Aspiring Evangelist
- Join Date
- Jan 2002
- Posts
- 428
Originally posted by takayuki
any problems with pair?
why did you leave?
-
05-15-2005, 12:49 PM #19Web Hosting Master
- Join Date
- Apr 2001
- Location
- Pittsburgh, PA
- Posts
- 1,306
Originally posted by crucialx
Thats a bit insecure, in a shared hosting environment FTP accounts should be chrooted to their home directory...
It's a fundamental tenet of shared hosting, unless you either 1) use a few tricks to make it less obvious, or 2) fundamentally change performance by running everything wrapped (think phpsuexec), which also means no mod_php.
Of course, keep in mind these are files that you are serving to the Web. It's not your e-mail or your home directory. If you have sensitive code, wrap it. If you have sensitive files, weigh the risk of 150 other users on the same server, and consider a dedicated server.
I am sure many hosts will join this thread and say "oh, you can fix that if you just know how" but see above. It's #1 or #2 or just be honest with your clients.
Kevin
-
05-15-2005, 01:00 PM #20Web Hosting Master
- Join Date
- Feb 2004
- Posts
- 2,197
This contributes a false sense of security and little more. The Web server still runs as nobody, and CGI scripts and mod_php run as user nobody - therefore any other user (via scripting) can see the other files the Web server can access.crucialparadigm - Affordable, Reliable, Professional :
Web Hosting
• 24/7 Support • Web Hosting • Reseller Hosting • Cloud/VPS Plans • Dedicated Servers •
-
05-15-2005, 01:04 PM #21Web Hosting Master
- Join Date
- Nov 2001
- Location
- The South
- Posts
- 5,408
php with safemode will help some but there are so many scripts that just won't run or won't run easily with safemode on that its almost useless to try and use it.
phpsuexec is a system -hog-
php with open_basedir is probably the best overall usable choice (along with other tricks).
CGI still has run of the full path, you can help stop that with a chrooted cgiwrapper but if it isn't already part of the software of the control panel it's nigh impossible to get it to work. Directadmin has this problem no chrooted shells, no chrooted cgi.
Making FTP chroot I don't think is too hard but it's a false sense of security, any user with a shell.php or shell.cgi will get right back to the / folder anyway.
Now CGI running as "nobody" how do those scripts read things like "blah.conf" when a user creates them if the scripts are nobody? Unless the conf file is marked 755 at least so user nobody can at least read the file anyway, which totally blows the purpose of the protection. The best bet for CGI is to run -as- the user and then the user can mark his files 700 instead of 755. Of course running chrooted AS the user is better but if that isn't in already it's a pain to add, we've been hounding the Directadmin team about chrooting cgi and shell for over a year now.Gary Harris - the artist formerly known as Dixiesys
resident grumpy redneck
-
05-15-2005, 01:06 PM #22Web Hosting Master
- Join Date
- Apr 2001
- Location
- Pittsburgh, PA
- Posts
- 1,306
Originally posted by crucialx
How is this contributing to a false sense of security? It is one extra layer of security which every host should implement, I see NO reason why this should not be implemented. I'm not saying its the only security measure which should be implemented, far from that.
Education is really the key. It's remarkable how many users will also assume that if they can see a file, they can modify it. They will swear up and down that they can, when of course they cannot. Not every OS is as simplistic as DOS
Kevin
-
05-15-2005, 01:08 PM #23Web Hosting Master
- Join Date
- Apr 2001
- Location
- Pittsburgh, PA
- Posts
- 1,306
Originally posted by Dixiesys
Now CGI running as "nobody" how do those scripts read things like "blah.conf" when a user creates them if the scripts are nobody? Unless the conf file is marked 755 at least so user nobody can at least read the file anyway, which totally blows the purpose of the protection.
Of course, if users are assuming that no account can see other account's public files, then they won't even consider that they might want to wrap certain code. They'll assume they are safe, when they are not.
Kevin
-
05-15-2005, 01:37 PM #24Web Hosting Master
- Join Date
- Feb 2004
- Posts
- 2,197
You can still educate a user without showing them all other web accessible accounts on the server.
crucialparadigm - Affordable, Reliable, Professional :
Web Hosting
• 24/7 Support • Web Hosting • Reseller Hosting • Cloud/VPS Plans • Dedicated Servers •
-
05-15-2005, 03:33 PM #25Disabled
- Join Date
- Dec 2004
- Posts
- 33
PHP with open_basedir would be a quick-easy fix.
Even if shared accounts couldn't be exploited, I wouldn't want to live in a glass house.