SuPHP / ruid2 -- Ownership question

J

jim.thornton

Verified User
Joined
Jan 1, 2008
Messages
334
I've been using suPHP on my CentOS server for years. With this solution I have to make sure that the owner of the php files within a user's website are all owned by that user.

I just installed a new DA server and did so with CustomBuild 2 and chose the default option using mod_ruid2. However, I just created a file in one account called index.html and it was still owned to root. When accessing that page on the frontend of the site the contents displayed instead of a 500 error like I would have gotten with suPHP.

Is this normal behaviour? I understood it that the mod_ruid2 was basically the same type of solution as suPHP in that users can only access files that are owned to them?
 
Hello,

More details on why you got a 500 error you can always see in apache logs (/var/log/httpd/domains/domain.com.error.log). Please check the logs and post here what you see there. Note to please post here only a related line, but not the whole error log.
 
My question is why didn't I get a 500 error when accessing an html file that was owned to root.

With suphp I would have gotten a 500 error.
 
That's suPHP which checks minimal UID and GID of a PHP file and drops 500 error if ownership/permissions are not correct.
 
zEitEr said:
That's suPHP which checks minimal UID and GID of a PHP file and drops 500 error if ownership/permissions are not correct.
Click to expand...

I thought that mod_ruid2 works the same way though? If not, why does it seem that it is the recommended way right now? How exactly is mod_ruid2 working?

It seems to me that getting a 500 error would be safer than allowing a user to execute/access a file that is not owned to them. right?
 
The file under question is a .html file. I don't use mod_php, so you probably need to check it with a PHP file.

Anyway, normaly an user can not read or copy a file owned by another user and can not upload it with wrong ownership, neither an user can chown it to another user. So you probably should not worry about it. For security reasons you might want to mount /home with nosuid bit, if you still worry about it.
 
mod_ruid2 can execute files in two different ways:

Code: 
-there are two main operation modes: stat and config
 1. config
 is default, you must define uid and gid. If no [ug]id is defined the default user and group are used.

 2. stat
 httpd setuid and setgid to uid and gid of requested filename(script)/directory
 this is good if you use mod_vhost_alias for virtual hosting

So if you configure it in httpd.conf to config; the file will always be executed under the user/group you specify in that very same httpd.conf (which is what DA is doing)

Or if you set it to stat, it would execute the file as the owner (root in your case).

These both seem quite safe. As stated by Alex a user can't change the owner so even stat would be fine; but the 'config' seems perfect for a shared hosting envoirment like DA boxes.

suPHP has got those checks in place indeed, they are rather unnecessary: if a file owner is different; someone with higher rigths has put it there so that's where the risk is; chmod checks are also unnecessary because if a subfolder is chmodded e.g. 777; outside users still cannot access it because parent dirs would not have the 777.
 
jim.thornton said:
I just installed a new DA server and did so with CustomBuild 2 and chose the default option using mod_ruid2. However, I just created a file in one account called index.html and it was still owned to root. When accessing that page on the frontend of the site the contents displayed instead of a 500 error like I would have gotten with suPHP.
Click to expand...
My understanding is that with mod_ruid2 html files will still be shown based on inedividual file owernship/permissions. Your file owned by root will still be shown if the permissions flags are at least ??4 (where ? is any valid entry) because apache is neither the owner or the group of the file.

PHP files, however, will only run if they're owned by the user.

At least that's my understanding. Someone please feel free to correct me if I'm wrong.

Jeff
 
nobaloney said:
PHP files, however, will only run if they're owned by the user.
Click to expand...

That's wrong.
mod_ruid2 spawn the process as the user that defined in RUidGid setting (in the relevant virtualhost).
If the user have read access to this file it will be execute, otherwise you'll see an error similar to this:
Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0
Click to expand...

for example, if the file owned by root, and everyone can read it, the file will be execute.
-rw-r----- 1 root root 33 Jun 24 11:52 i.php - will show permission error
-rw-r--r-- 1 root root 33 Jun 24 11:52 i.php - will execute
Click to expand...
 
I thought that suphp added an excellent layer of security for shared hosting, did it not? The purpose being that someone couldn't execute a malicious script in another users account.

For example, user A and user b are both there. User B executes a script within user A's account. Let's say the file is 644 therefore they would be able to read the file. However, the file is in another account structure all together.
 
suPHP check for the owner / group, mod_ruid dosen't.
therefore, you should keep open basedir on, so users won't be able to access other user's home dir.
 
Since all users file are executed as the user itself, it can't put his files to another user because he doesn't have the right to enter other users folder to begin with.
 
jim.thornton said:
I thought that suphp added an excellent layer of security for shared hosting, did it not? The purpose being that someone couldn't execute a malicious script in another users account.
Click to expand...

Check this http://www.directadmin.com/features.php?id=961 with this enabled feature users can not see files in each other's public_html folders. Since that that does not much matter what to use mod_ruid2 or mod_suphp. My choice is for PHP as CGI, as with it I can use per user/domain php.ini. Which can be achived now with the help of CB 2.0 not only with suPHP.
 
BestBoard said:
That's wrong.
mod_ruid2 spawn the process as the user that defined in RUidGid setting (in the relevant virtualhost).
If the user have read access to this file it will be execute
Click to expand...
I thought I was just oversimplifying but maybe I'm just wrong. :(

I've thought that current builds of DirectAdmin protect the user' home directory. But maybe they don't:

Here's an example of a newly created user on one of my servers:
Code: 
drwx--x---   5 three69    access      4096 Jun 21 20:13 three
The access group contains the following users (copy/paste from /etc/group directory:
Code: 
access:x:506:apache,nobody,mail,majordomo,daemon,ftp
If mod_ruid2 runs apache as the user (as I believe it does) and not as apache, doesn't that effectively lock any other user out of reading any files?

Well, maybe not, since my .html files and php files get uploaded chmod 644.

So my quesiton is now: does mod_ruid2 offer any protection at all in this configuration?

As Arieh points out above, probably yes, because the /home/* directories are limited to the user and to members of access, and since apache for other users runs as the other user. So I still think mod_ruid2 offers the security.

I'll be anxiously awaiting replies.

Thanks.

Jeff
 
nobaloney said:
I thought I was just oversimplifying but maybe I'm just wrong. :(

I've thought that current builds of DirectAdmin protect the user' home directory. But maybe they don't:

Here's an example of a newly created user on one of my servers:
Code: 
drwx--x---   5 three69    access      4096 Jun 21 20:13 three
The access group contains the following users (copy/paste from /etc/group directory:
Code: 
access:x:506:apache,nobody,mail,majordomo,daemon,ftp
If mod_ruid2 runs apache as the user (as I believe it does) and not as apache, doesn't that effectively lock any other user out of reading any files?

Well, maybe not, since my .html files and php files get uploaded chmod 644.

So my quesiton is now: does mod_ruid2 offer any protection at all in this configuration?

I'll be anxiously awaiting replies.

Thanks.

Jeff
Click to expand...

You can't enter a /home/$user since others don't have any access to it. Simply try it by loggin into ssh as a user and go to another /home/$user.

You can't access anything in a subdirectory if you don't have access to the full path.
 
zEitEr is correct. Both suPhp and mod_ruid2 will run php as the User.
As such, the "access" group and 750 on /home/user will block processes running as some other User account. (note Admin/Reseller accounts do this on /home/admin/domains, as the backup folders need to be chmod a+x)

If you're running just CLI without mod_ruid2, and if php run as "apache", then you'd be relying solely on open_basedir to do the blocking for you.
It does work, but more layers of security are better than fewer layer of security, in case any single layer has a bug or loophole.

mod_ruid2 is the default for CustomBuild 2.0 installs. It offers all of the security, mentioned above, but also gives us the speed and low memory usage of mod_php/CLI.
suPhp offers many flexibilities, but does have a somewhat "slower" design where the php binary is run/loaded for each request... although, boxes are so fast these days, and OS file systems cache loaded files, it probably doesn't matter much.
The newer fancy php technologies would be php-fpm (php server) and fastcgi (like a persistent suPhp)... but they have a much higher level of complexity to obtain their performance... but in cases where you need it, it may be worth it.

John
 
You must log in or register to reply here.
Back
Top