Guess no one really knows what to do 
)
I have
php_admin_value open_basedir &/home/user:/tmp&
set for every VirtualHost entry in htttpd.conf. But recently I started getting errors in PHP scripts so I deleted that line on some accounts. And now same error still happens, but if I hit refresh it comes OK.
Anyone has some tips for openbasedir?
Thanks
)I have
php_admin_value open_basedir &/home/user:/tmp&
set for every VirtualHost entry in htttpd.conf. But recently I started getting errors in PHP scripts so I deleted that line on some accounts. And now same error still happens, but if I hit refresh it comes OK.
Anyone has some tips for openbasedir?
Thanks
[quote:f2393b3370][i:f2393b3370]Originally posted by dzevad[/i:f2393b3370]
Guess no one really knows what to do)
I have
set for every VirtualHost entry in htttpd.conf. But recently I started getting errors in PHP scripts so I deleted that line on some accounts. And now same error still happens, but if I hit refresh it comes OK.
Anyone has some tips for openbasedir?
Thanks[/quote:f2393b3370]
Have you got this in the VirtualHost?
php_admin_value safe_mode 0
php_admin_value open_basedir &/home/user:/tmp&
That should work.
Is safe mode on or off in php.ini?
Regards,
Norman
Guess no one really knows what to do
)I have
set for every VirtualHost entry in htttpd.conf. But recently I started getting errors in PHP scripts so I deleted that line on some accounts. And now same error still happens, but if I hit refresh it comes OK.
Anyone has some tips for openbasedir?
Thanks[/quote:f2393b3370]
Have you got this in the VirtualHost?
php_admin_value safe_mode 0
php_admin_value open_basedir &/home/user:/tmp&
That should work.
Is safe mode on or off in php.ini?
Regards,
Norman
[quote:db7f687c26]
Have you got this in the VirtualHost?
php_admin_value safe_mode 0
php_admin_value open_basedir &/home/user:/tmp&
That should work.
Is safe mode on or off in php.ini?
Regards,
Norman[/quote:db7f687c26]
Safe mode is off in php.ini, but line
php_admin_value safe_mode 0
doesn't help much, it still sometimes shows error (after clicking refresh it's ok).
After I commented all
php_admin_value open_basedir &/home/user:/tmp&
lines in httpd.conf I don't get error any more. It's strange since for my virtual host there was no such line anyway.
Have you got this in the VirtualHost?
php_admin_value safe_mode 0
php_admin_value open_basedir &/home/user:/tmp&
That should work.
Is safe mode on or off in php.ini?
Regards,
Norman[/quote:db7f687c26]
Safe mode is off in php.ini, but line
php_admin_value safe_mode 0
doesn't help much, it still sometimes shows error (after clicking refresh it's ok).
After I commented all
php_admin_value open_basedir &/home/user:/tmp&
lines in httpd.conf I don't get error any more. It's strange since for my virtual host there was no such line anyway.
Safe_mode, opendir, etc. are better than not, but trivial. A PHP script can be coded to bypass these settings anyway. I don't believe that it relates very well to 'security'. I'd suggest people run PHP as CGI if they are concerned about security, and use SuEXEC for CGI. You can configure the web server to run PHP scripts in their usual manner, so users' don't need to change the permissions for .php files, nor rename it to any other file extension, nor add #!/usr/bin/php to the top of the script. PHP embedded in the httpd process is obviously faster, but few clients will run scripts written well enough anyway and usually end up consuming a lot of resources. With SuEXEC and CGI you can limit their resource usage, have better tracking or processes and abuse, spam, etc.
I personally don't see a huge increase in process time with PHp as a module or as CGI. Of course this doesn't help for other modules like mod_perl, mod_python, etc., as mentioned earlier, so a similar solution would need ot be created for those if you use them. For that matter, some type of wrapper (which would need to be carefully coded with a lot of things in mind) would be best and just run it so anything (module or not) will pass through it. Of course that's not an easy task and worse than hacking the Apache source or modifying modules and components, would having to pass through this wrapper which could result in a slight decrease in performance (which goes without saying for each additional function that needs to be run).
However, since most servers run PHP and CGI, PHP *as* CGI might be a valid solution, as you can then safely restrict user's from ever being able to access the other user's account directories from FTP, shell, the web server (via CGI) and so on. Though, some people really frown on the idea of running PHP as CGI, but I think it's a pretty good solution for a lot of problems I consider more alarming than a slight speed increase or overhead reduction -- again, since few scripts seem to be coded well anyway and consume a lot of resources, at least with SuEXEC you can better control them.
I personally don't see a huge increase in process time with PHp as a module or as CGI. Of course this doesn't help for other modules like mod_perl, mod_python, etc., as mentioned earlier, so a similar solution would need ot be created for those if you use them. For that matter, some type of wrapper (which would need to be carefully coded with a lot of things in mind) would be best and just run it so anything (module or not) will pass through it. Of course that's not an easy task and worse than hacking the Apache source or modifying modules and components, would having to pass through this wrapper which could result in a slight decrease in performance (which goes without saying for each additional function that needs to be run).
However, since most servers run PHP and CGI, PHP *as* CGI might be a valid solution, as you can then safely restrict user's from ever being able to access the other user's account directories from FTP, shell, the web server (via CGI) and so on. Though, some people really frown on the idea of running PHP as CGI, but I think it's a pretty good solution for a lot of problems I consider more alarming than a slight speed increase or overhead reduction -- again, since few scripts seem to be coded well anyway and consume a lot of resources, at least with SuEXEC you can better control them.
[quote:7c03b6bbe3][i:7c03b6bbe3]Originally posted by Tim Greer[/i:7c03b6bbe3]
Safe_mode, opendir, etc. are better than not, but trivial. A PHP script can be coded to bypass these settings anyway. I don't believe that it relates very well to 'security'. I'd suggest people run PHP as CGI if they are concerned about security, and use SuEXEC for CGI. You can configure the web server to run PHP scripts in their usual manner, so users' don't need to change the permissions for .php files, nor rename it to any other file extension, nor add #!/usr/bin/php to the top of the script. PHP embedded in the httpd process is obviously faster, but few clients will run scripts written well enough anyway and usually end up consuming a lot of resources. With SuEXEC and CGI you can limit their resource usage, have better tracking or processes and abuse, spam, etc.
I personally don't see a huge increase in process time with PHp as a module or as CGI. Of course this doesn't help for other modules like mod_perl, mod_python, etc., as mentioned earlier, so a similar solution would need ot be created for those if you use them. For that matter, some type of wrapper (which would need to be carefully coded with a lot of things in mind) would be best and just run it so anything (module or not) will pass through it. Of course that's not an easy task and worse than hacking the Apache source or modifying modules and components, would having to pass through this wrapper which could result in a slight decrease in performance (which goes without saying for each additional function that needs to be run).
However, since most servers run PHP and CGI, PHP *as* CGI might be a valid solution, as you can then safely restrict user's from ever being able to access the other user's account directories from FTP, shell, the web server (via CGI) and so on. Though, some people really frown on the idea of running PHP as CGI, but I think it's a pretty good solution for a lot of problems I consider more alarming than a slight speed increase or overhead reduction -- again, since few scripts seem to be coded well anyway and consume a lot of resources, at least with SuEXEC you can better control them.[/quote:7c03b6bbe3]
Tim Greer how could you be safe from perl program such this ?
http://www.rohitab.com/cgiscripts/cgitelnet.html
(.. this is not a ssh client , it's a perl program which emulate shell using perl commands) .
Safe_mode, opendir, etc. are better than not, but trivial. A PHP script can be coded to bypass these settings anyway. I don't believe that it relates very well to 'security'. I'd suggest people run PHP as CGI if they are concerned about security, and use SuEXEC for CGI. You can configure the web server to run PHP scripts in their usual manner, so users' don't need to change the permissions for .php files, nor rename it to any other file extension, nor add #!/usr/bin/php to the top of the script. PHP embedded in the httpd process is obviously faster, but few clients will run scripts written well enough anyway and usually end up consuming a lot of resources. With SuEXEC and CGI you can limit their resource usage, have better tracking or processes and abuse, spam, etc.
I personally don't see a huge increase in process time with PHp as a module or as CGI. Of course this doesn't help for other modules like mod_perl, mod_python, etc., as mentioned earlier, so a similar solution would need ot be created for those if you use them. For that matter, some type of wrapper (which would need to be carefully coded with a lot of things in mind) would be best and just run it so anything (module or not) will pass through it. Of course that's not an easy task and worse than hacking the Apache source or modifying modules and components, would having to pass through this wrapper which could result in a slight decrease in performance (which goes without saying for each additional function that needs to be run).
However, since most servers run PHP and CGI, PHP *as* CGI might be a valid solution, as you can then safely restrict user's from ever being able to access the other user's account directories from FTP, shell, the web server (via CGI) and so on. Though, some people really frown on the idea of running PHP as CGI, but I think it's a pretty good solution for a lot of problems I consider more alarming than a slight speed increase or overhead reduction -- again, since few scripts seem to be coded well anyway and consume a lot of resources, at least with SuEXEC you can better control them.[/quote:7c03b6bbe3]
Tim Greer how could you be safe from perl program such this ?
http://www.rohitab.com/cgiscripts/cgitelnet.html
(.. this is not a ssh client , it's a perl program which emulate shell using perl commands) .
[quote:ae0e39a946][i:ae0e39a946]Originally posted by Radio_Head[/i:ae0e39a946]
Tim Greer how could you be safe from perl program such this ?
http://www.rohitab.com/cgiscripts/cgitelnet.html
(.. this is not a ssh client , it's a perl program which emulate shell using perl commands) .
[/quote:ae0e39a946]
I didn't look at the script, but this solution was for running as the user. Any script that gives up an interface would still give up that interface. Be it the global web server user itself or just the user, makes no difference. That is another issue altogether. Any CGI or PHP script can run any command/program on the system it is allowed access to.
The only way around that, is to limit what tools on the system can be accessed or executed by whatever user in question as to prevent CGI or PHP scripts from being able to run them. Chrooting the user and their own Apache process (therein allowing you to run as module versions and still have it be their own user with their own limits) and having their own programs is the best solution so they are jailed in their own environment and their 'shell emulation' is trivial to nil.
Tim Greer how could you be safe from perl program such this ?
http://www.rohitab.com/cgiscripts/cgitelnet.html
(.. this is not a ssh client , it's a perl program which emulate shell using perl commands) .
[/quote:ae0e39a946]
I didn't look at the script, but this solution was for running as the user. Any script that gives up an interface would still give up that interface. Be it the global web server user itself or just the user, makes no difference. That is another issue altogether. Any CGI or PHP script can run any command/program on the system it is allowed access to.
The only way around that, is to limit what tools on the system can be accessed or executed by whatever user in question as to prevent CGI or PHP scripts from being able to run them. Chrooting the user and their own Apache process (therein allowing you to run as module versions and still have it be their own user with their own limits) and having their own programs is the best solution so they are jailed in their own environment and their 'shell emulation' is trivial to nil.
Tim is right. PHP running as a CGI script is a much more secure solution. At least when a command is being executed through a CGI shell emulator, you can see which user is doing that through top or ps and kick them out if you find there's reason to. And, unlike static web pages, scripts may contain sensitive information like database passwords. If they can do their thing without having to have universal read permissions, that's excellent from the security standpoint.
-Dario
-Dario
A really nice feature of cpanel would be the ability to edit php safe mode settings via httpd.conf / WHM on a domain basis.
Anyone have idea how to automatically add the php_admin_value ... ... in the VirtualHost for newly added accounts automatically?
what i mean:
When i add Hosting account- xyz.com, then in the httpd.conf in the VirtualHost entries of xyz.com i want php_admin_value open_base_dir /home/xyzcom to be automatically inserted.
Thanks
<edit: sorry i think new thread shud be better place to ask, so i opened a new thread>
what i mean:
When i add Hosting account- xyz.com, then in the httpd.conf in the VirtualHost entries of xyz.com i want php_admin_value open_base_dir /home/xyzcom to be automatically inserted.
Thanks
<edit: sorry i think new thread shud be better place to ask, so i opened a new thread>
Last edited:
Although a good Control Panel can greatly help, with some of the maintainence required by a SysAdmin, it does not replace doing most of the necessary tweaking & editing -- manually required. A nice feature of any Control Panel would allow for setting up a few hundred "if, while, do" loops, to cover whatever we can think of, so we don't have to do them manually. Unfortunately, that type of Control Panel will not be available within our lifetime.
