PHP enable/disable bug :Can be overridden

netspace

Verified User
Joined
Oct 8, 2003
Messages
29
The PHP disable checkbox in DA is only disassociating mime-types and a simple mime-type addition brings back php to any site.

Add this to .htaccess and upload and php starts working on that domain again...

AddType application/x-httpd-php .php .php3 .phtml .html .htm


DA should have a permanent PHP-disable that cannot be overridden like this...I haven't tried it with cgi, but I suppose cgi will also work simply by adding mime-types.
 
As far as I understood it, it turns the php_engine_flag (sp?) on or off in the VirtualHost's apache conf too. Seems odd that that wouldn't stop it from running.

Matt
 
Hello,

The .htaccess method may in fact work for enabling php. I'm pretty sure it works for turning on cgi scripts. Apart from disabling .htaccess files, I'm not aware of a way to prevent certain .htaccess commands to turn things on again. If there is a way that someone knows of, let us know :)

John
 
Hey...sorry for the scare. Its an issue but a minor one.

DA is in fact disabling PHP for the domain...but NOT for the ~user access method. I had earlier tried it only using IP/~username/info.html (since the nameservers had not resolved by then)

So, its still a prob...but a relatively minor one.
 
Would it be possible to have DA monitor those files, and everytime any change is made have it compare to the admin overrides and make correct changes if necassary?
 
Ok, I found the problem and the simple fix.

DA is using php_flag engine on/off in the .conf files. But these directives can be overridden.

It should instead be using NON-overrideable php flags...

php_admin_flag engine on/off

In the folder /usr/local/directadmin/data/templates/, there are these 4 files....

virtual_host.conf
virtual_host_sub.conf
virtual_host_secure.conf
virtual_host_secure_sub.conf


In this php_flag should be replaced with php_admin_flag and then users cannot override php disable with .htaccess


Another question to DA : Why do you keep "open_basedir" commented out. Its rather critical to system security...and everytime DA updates to new version you replace my modified ones !!! That's work everytime DA updates. Please find some way to make modifications STICK thru version updates (minor versions at least).

Right now, everytime DA updates...I have to and edit those files again to enable "open_basedir".
 
Hello,

Thanks for the note, I've added it to the versions system.

Re: overwrite:

If you want to have your own versino of the virtual_host*.conf files, then you must copy them to the custom directory and make any changes from there. DA searches that dir *first* and uses those if they exist. If they don't, the defaut DA ones are used.

The only reason we've commented it out is because when we first released it, it caused havok for some people. I believe that the current setup should work, although commented out. Another oddity was the fact that even with /home/user setup, some scripts were being locked out becuase it said their script wasn't in /home/user2 ... the paths in the virtualhosts were in fact setup correctly, and could be a bug in apache/php which may (or may not) be related to the fix in php 4.3.5: "Fixed INI leak between Apache virtual hosts." (http://www.php.net/release_4_3_5.php).

John
 
Back
Top