Re: [cobalt-developers] RE: file permissions

[Michael Stauber <devel@xxxxxxxxxxxxxx>]

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
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer