suexec allows deleting files which owner is root

[xerc]

Hi folks,

I used the Lenny Perfect Server Tutorial to install my server.
ISPConfig 3.0.1.5

I use php fastcgi in all sites. My problem was that php was not allowed to write to files in the docroot, even if owner and group are correct (webXX and clientXX), rights of all directories and files were 755. Then I tried 775, and suddenly php was allowed to write in the docroot.

"That's not so pretty" I thought, so I looked around and found suexec.
I didn't found a switch in ISPConfig to enable suexec, so I added it manually to my vhost for testing:

<VirtualHost *:80>
SuexecUserGroup web13 client4

Now php could write in the docroot with 755. "Nice" I thought. Until I tested it in the depth:

First problem:
-r--r--r-- 1 root root 54 2009-10-21 18:11 test.php

test.php can be executed, even if owner is root.

Second Problem:
test.php can delete files owned by root, even if I set owner of test.php to web13 and group to client4.

test.php:

PHP Code:

<?php
unlink("deleteme");
?>

-r--r--r-- 1 web13 client4 54 2009-10-21 18:11 test.php
-r--r--r-- 1 root root 0 2009-10-21 19:44 deleteme

Deleting is always possible.

Why is this possible? I thought suexec would prevent something link this.

Third problem:
-rwsr-xr-- 1 root www-data 14K 2009-07-14 22:47 /usr/lib/apache2/suexec

In http://httpd.apache.org/docs/2.0/suexec.html I read that suexec has to be owned by apache, but here it is owned by root. If I change the owner to www-data, apache won't stat (no suexec wrapper found).

EDIT:
When I do "su web13" I stay root, but I get no error.
/var/log/sulog says:
SU 10/22 11:21 + pts/1 root-web13

[till]

I didn't found a switch in ISPConfig to enable suexec

There is a checkbox labeled "suxec" in the website settings. Do not edit the vhosts manually!

test.php must be owned by the user and group of the website and not root. None of your users is able to create files as root, you simply created the file with the root user and so the file has the wrong owner.

[xerc]

Hi,
i found the checkbox, thanks a lot.

But why can the phpscript, even if it is owned by web13, delete a file which owner is root? If I install phpshell, I can even start shellscripts as web13 which owner is root, if they lie in the webroot.

[till]

This depends on the permissions of the file and not just the owner. If you run:

chwon root:root myfile.sh
chmod 700 myfile.sh

then nobody except of the root user itself can modify or delete it.

But if a file has permissions for another group or even others to modify or run it, the members of the group or others can use or edit the file. Thats theway the linux permission system works.

[xerc]

Hi Till,

seems like you haven't read my first post completly.

test.php:

PHP Code:

<?php
unlink("deleteme");
?>

-r--r--r-- 1 web13 client4 54 2009-10-21 18:11 test.php
-r-------- 1 root root 0 2009-10-21 19:44 deleteme

Deleting of file "deleteme" is always possible when I execute test.php in browser.

That's what it's all about, this should not be possible.

[till]

Seems as you have not read my post properly I told you that test.php has to be owned by the user and group of the website and not root.

[xerc]

please look at my previous post. There you can see that test.php is owned by web13:client4. So definetly not root.

Greetings

[till]

And you called the php script trogh the webbrowser and nit not executed it on the shell? Then you must have a serious problem with the linux permission system on your server.

Please create a php script owned by the web user and group with the following content:

<?php
system('whoami');
?>

[xerc]

Yes, I called the script from a browser.

With suexec it says "web13" and I can delete the file owned by root.
If I deactivate suexec it says "www-data" and i can't delete the file owned by root.

[giftsnake]

using suPHP (system('whoami'); shows web1) i can delete files owned by root and permissions 700 also.

i cant delete files in /var/www/domain.com/ but in web/deletefolder/ (when deletefolder has permissions for web1 to access, but file is still 700 and root!)


rmdir('folder'); works like a charm too!