Page 1 of 3 123 LastLast
Results 1 to 25 of 52
  1. #1

    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

  2. #2
    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?

  3. #3
    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

  4. #4
    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

  5. #5
    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

  6. #6
    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.

  7. #7
    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 way
    init.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

  8. #8
    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

  9. #9
    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.

  10. #10
    Join Date
    Aug 2003
    Location
    PA
    Posts
    1,914
    Of course this is a big security problem.
    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

  11. #11
    Join Date
    Jun 2001
    Posts
    747
    This company, by any chance, doesn't start with the letter c...?

    I had the exact some experience a few years back. Support weren't too interested...

  12. #12
    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
    You are right indeed, but in most cases Apache runs as an unprivileged user (e.g. 'nobody') and in most cases access for others must be enabled.

    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.

  13. #13
    someone asked who the host is. it's pair.com.

    anyone hosted with pair want to chime in?

  14. #14
    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?
    I was with pair about 18 months ago and if I recall correctly this was the case back then as well.

  15. #15
    any problems with pair?

    why did you leave?

  16. #16
    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'.

  17. #17
    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 •

  18. #18
    Join Date
    Jan 2002
    Posts
    428
    Originally posted by takayuki
    any problems with pair?

    why did you leave?
    Who are you talking to?

  19. #19
    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...
    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.

    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

  20. #20
    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.
    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.
    crucialparadigm - Affordable, Reliable, Professional :
    Web Hosting
    24/7 Support • Web Hosting • Reseller Hosting • Cloud/VPS Plans • Dedicated Servers •

  21. #21
    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

  22. #22
    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.
    It gives the novice user the impression that no account on the server can access public files of other accounts, which isn't true. Therefore the novice user will not think to wrap sensitive scripts, for example. It's slightly better than just a false sense, as I said, but you have to offset that against the misleading effect it can have.

    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

  23. #23
    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.
    Well, if there is something sensitive in "blah.conf" such as MySQL password, then the script should definitely be wrapped and therefore running as the user.

    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

  24. #24
    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 •

  25. #25
    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.

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •