cgi suexec / cPanel server
- Thread starter ffeingol
- Start date
Yep, it's there, but does not seem to be working:
Here is the code we're running:
When we access the page we get:
hello world
*x *
So the script is able to open /var/cpanel/whmtheme which is well outside the sites "home directory" and I though would be unaccessible.
TIA,
Frank
Code:
<VirtualHost x.x.x.x>
ServerAlias www.xx.xx
ServerAdmin webmaster@xx.xx
DocumentRoot /home/xx/public_html
User xxx
Group xxx
ServerName xx.xx
<IfModule mod_suphp.c>
suPHP_UserGroup xxx xxx
</IfModule>
<IfModule mod_php4.c>
php_admin_value open_basedir "/home/xxx:/usr/lib/php:/usr/local/lib/php:/tmp:/opt/lsws/share/autoindex"
</IfModule>
<IfModule mod_php5.c>
php_admin_value open_basedir "/home/xxx:/usr/lib/php:/usr/local/lib/php:/tmp:/opt/lsws/share/autoindex"
</IfModule>
User xxx
Group xxx
BytesLog /usr/local/apache/domlogs/xx.xx.xx-bytes_log
CustomLog /usr/local/apache/domlogs/xx.xx.xx combined
ScriptAlias /cgi-bin/ /home/xxx/public_html/cgi-bin/
</VirtualHost>
Code:
#! /usr/local/bin/perl
print "Content-type: text/html\n\n";
print "<html><body>\n";
print "hello word\n";
open(PASSW, "/var/cpanel/whmtheme");
while (<PASSW>)
{
print "*$_ *\n";
}
print "</body></html>\n";hello world
*x *
So the script is able to open /var/cpanel/whmtheme which is well outside the sites "home directory" and I though would be unaccessible.
TIA,
Frank
If the user have read permission on that file, then the script can still read it. LSWS only guarantee itself won't be tricked to serve anything out side the document root, it has no control over a script unless the script is placed in a chroot jail.
You can make the script run slower and check the process uid.
You can make the script run slower and check the process uid.
Can you explain this a bit more?
I ran a quick test and you are correct that Apache suexec can read outside the document root (something I did not think it could do). suexec, however, enforces that the uid/gid match or it won't run the script. Is this possible to do with LSWS when it's reading the Apache config?
TIA,
Frank
I ran a quick test and you are correct that Apache suexec can read outside the document root (something I did not think it could do). suexec, however, enforces that the uid/gid match or it won't run the script. Is this possible to do with LSWS when it's reading the Apache config?
TIA,
Frank
Hmm,
Sorry to keep taking right turns here, but either I'm not understanding or suexec simply works "differenty" under LSWS. In a default cPanel install let's say we have the following:
/home/user-1/
/home/user-1/public_html
/home/user-2/
/home/user-2/public_html
under /home/user-1 I create a simple text file (let's just call it junk.txt). In user-2 I created a small cgi program (perl) that opened /home/user-1/junk.txt. Under Apache suexec I got a 500 error and a message in the suexec log that the uid/gid does not match (so the file could not be opened). LSWS otoh easily opened the file.
I'm hoping I just have something configured wrong.
TIA,
Frank
Sorry to keep taking right turns here, but either I'm not understanding or suexec simply works "differenty" under LSWS. In a default cPanel install let's say we have the following:
/home/user-1/
/home/user-1/public_html
/home/user-2/
/home/user-2/public_html
under /home/user-1 I create a simple text file (let's just call it junk.txt). In user-2 I created a small cgi program (perl) that opened /home/user-1/junk.txt. Under Apache suexec I got a 500 error and a message in the suexec log that the uid/gid does not match (so the file could not be opened). LSWS otoh easily opened the file.
I'm hoping I just have something configured wrong.
TIA,
Frank
I might be wrong, but I believe the 500 error is not because the CGI accessing another user's file, Apache will not check what the script does. Apache suEXEC has many restrictions, in this case, maybe the requirement of ownership of the script does not meet. You will get 500 error even when the script trying to access a file under user-2's home directory. Apache simple wont run the script no matter what. If all the requirement of Apache CGI suEXEC has been met, the script should has not problem access user-1's file, same result as with LSWS.
To prevent one user from reading or writing another user's file, the file system permission need to be set properly. If you make user-1's home directory NOT world readable, then scripts run under user-2 will not able to access user-1's files.
To prevent one user from reading or writing another user's file, the file system permission need to be set properly. If you make user-1's home directory NOT world readable, then scripts run under user-2 will not able to access user-1's files.
Sorry, not trying to stir up trouble, but I'm trying to evaluate LSWS as a "drop in" replacement for Apache on cPanel. Here is the line from the suexec_log:
You are correct that Apache does not check the file ownership or what the script does, but suexec does. While I agree that permissions may not be optimal, it works as we expect under Apache/suexec and it works differently under LSWS. We just need to figure out a way to make LSWS work like Apahce/suexec.
TIA,
Frank
Code:
[2007-08-02 13:13:10]: error: target uid/gid (32003/32005) mismatch with directory (32003/32005) or program (99/99) or trusted user (0/10)TIA,
Frank
Not a problem.
Some of the restriction of Apache suEXEC is not necessary to me, as when you make suEXEC happy with the script permission, the end result might be exactly as what LSWS produce without those restrictions.
Basically, we want our suEXEC implementation easy to use while maintain the same level of security as Apache's.
In this case, what you need to do to make Apache suEXEC happy with the script? I assume you need to fix something like ownership/permission of the script. After the fix, does the script work differently than what LSWS does now?
We are open to suggestions on enhancing the security of our product, and we will be very happy to implement a useful feature.
I might be completely wrong as I am not a expert on Apache suEXEC, your current Apache suEXEC may not allow a normal user to execute any CGI script in suEXEC mode, as it may require the script owned by 99/99 or a user other than the user who own the directory, it is not possible for a normal user to change the file ownership.
Some of the restriction of Apache suEXEC is not necessary to me, as when you make suEXEC happy with the script permission, the end result might be exactly as what LSWS produce without those restrictions.
Basically, we want our suEXEC implementation easy to use while maintain the same level of security as Apache's.In this case, what you need to do to make Apache suEXEC happy with the script? I assume you need to fix something like ownership/permission of the script. After the fix, does the script work differently than what LSWS does now?
We are open to suggestions on enhancing the security of our product, and we will be very happy to implement a useful feature.
I might be completely wrong as I am not a expert on Apache suEXEC, your current Apache suEXEC may not allow a normal user to execute any CGI script in suEXEC mode, as it may require the script owned by 99/99 or a user other than the user who own the directory, it is not possible for a normal user to change the file ownership.
Well I think this one is necessary First ignore those other uid/gid's. I'm 99% sure it means that it can't be one of those (they are nobody and root). The closest thing I can equate this functionality to is php openbasedir. We simply could not rely on clients to keep directory permissions correct. There are way too many open source packages that say "chmod 777 ...".
I'm going to send you more details via PM as I don't want to publish these details in public.
Frank
First ignore those other uid/gid's. I'm 99% sure it means that it can't be one of those (they are nobody and root). The closest thing I can equate this functionality to is php openbasedir. We simply could not rely on clients to keep directory permissions correct. There are way too many open source packages that say "chmod 777 ...".I'm going to send you more details via PM as I don't want to publish these details in public.
Frank
The way Unix/Linux file system permission works is that if the parent directory is not world readable, then its sub-directories are not world readable no matter what the permission mask is on the subdirectory.
So, if the permission of a user's home directory has been set properly, then other user cannot access any file under that user's home directory no matter what is the permission mask of individual file or directory. Usually, the permission of a user's home directory is set properly by the control panels.
Apache suEXEC care about script file ownership because it run script under the same UID of the owner of the file, while LSWS run everything under the UID of the owner of document root directory, regardless the UID of a specific CGI script.
So, if the permission of a user's home directory has been set properly, then other user cannot access any file under that user's home directory no matter what is the permission mask of individual file or directory. Usually, the permission of a user's home directory is set properly by the control panels.
Apache suEXEC care about script file ownership because it run script under the same UID of the owner of the file, while LSWS run everything under the UID of the owner of document root directory, regardless the UID of a specific CGI script.