Hi Ian, > Not sure what you're getting at - would you care to elaborate?
Sure, lets see if I can answer your questions and help you to understand it better. I don't think you've got something wrong on your server. It's just the standard behaviour of the Cobalt server appliances. > >> Depends on the file permission. If the order file is created with > >> world-readable permission, then the answer is yes. > > So in your example, since all files have world-read and some have > world-execute, then any user from any site will be able to view them. That's correct. You see, in the example I provided the files were simply uploaded by FTP by the webmaster. No permissions or ownerships were altered manually. So that was a pretty much stock hosting environment as you'd see it on any virtual site on a RaQ where Frontpage Extensions are not enabled. Except for the .htaccess file in the example, which I had created manually to stop external references to local images. In that default environment any user with shell access can login by SSH or Telnet and is then able to see into the /web directories of other virtual sites. That's because of the default r-x permissions (read & execute). As another gentlemen pointed out: Most files in there are publically visible with a browser from the net anyway, so it shouldn't hurt that much. However, we can all imagine a few files which we'd mind if someone examined them. Like some PHP or Perl-Scripts whose sourcecode woulndn't be viewable from the net. The only really protected directories are the users's home directories itself. Example: /home/site/site1/users/site1admin That's only viewable for user root, admin and site1admin. Where the read access for anyone with shell access gets kinda problematic is with PHP and Perl-Scripts which need to store login data to the MySQL database (or other information like login data for the admin user of that application) in a configuration file. Imagine this: User A creates a forum using PHP and MySQL. Malicious user B has shell access and for whatever reason he decides to tick user A off. So he logs in by Telnet/SSH, goes to the webspace of user A and reads the configuration file for the PHP-script to find out the username and password for either the PHP-application or the login data for the applications admin-backend. With that he then erases user A's MySQL database or destroys the forum database through the Forums Admin interface. Could user A have prevented the problem with setting proper permissions on the configuration file? The answer to that is neither a straight YES nor is it a NO, because if the config file is not world readable, then Apache will be unable to read it and the PHP applocation will therefore not run. Had the user used PERL instead of PHP for his application, then the answer would have been YES, as the cgiwrapper usually runs under the username of the owner of the script. In that case world readable permissions are not needed. But as pointed out in a previous message: You don't need shell access to spy on other user's data, because a malicious user with PHP enabled on his website could write a PHP script for the same purpose. Or he could download an existing file explorer written in PHP (there are a few of those) which work similar to internet explorer on Windows and allow you to explore and to wander around on the filesystem. As nice as PHP is (modern hosting can't do without), it comes with several security implications which people should (IMHO) be aware of. -- Mit freundlichen Gr��en / With best regards Michael Stauber [EMAIL PROTECTED] Unix/Linux Support Engineer _______________________________________________ cobalt-developers mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-developers
