So, here the way to change the defaults, its really easy and I had posted this last week already but here for refernce again the step: Edit the file: /usr/local/ispconfig/server/conf/vhost.conf.master and replace all lines (the lin exists 4 times in the file): AllowOverride Indexes AuthConfig Limit with: AllowOverride Indexes AuthConfig Limit FileInfo --- Update:fixed typo in path.
Hey till, thanks for the reply. I figured that it would not be a decision a dev would make, I just think that your way of handling it was back to front (which is entirely your prerogative, obviously) - instead of disabling rewrite it might have been better to offer an option to disable it. As it is there are no options at all other than to renable one site at a time retroactively, which is no option in real life. Anyhow, what is done is done. I appreciate the slight security risks of rewrite and understand your concerns as to not having problems from users who might suffer because it is there. From this end of things, though, things look very different. To satisfy both the pro and anti rewrite brigades, why not reenable it globally and then have some way of disabling it afterwards (i.e. locking the sites that need it down with it enabled on all of them in one click). Then afterwards make some option to enable it, as you and the antis want, on a per *new* site basis. The enabling per site option would have to be sticky though. All non-trivial to do, I'm sure, but as ISPConfig 3 shows, you're in it for the long haul. So that kind of setup (options per site and global/ rewrites on or off/ all sticky) as non trivial as it might be for you to code into the script would pay didident in the long term. Just my take on it. Whatever you decide, I for one would really like to see it reenabled just for the immediate future anyway, if only to calm things down! Also would like to say, despite all of the above and this present problem we are having, that ISPConfig 3 is excellent. Just the ultra-effective installation script is outstanding, let alone what the main script does once it starts work. Can't imagine the work that has gone into getting it this far, and kudos to you for that. But just for now, please bring back the rewrites, before I and a lot of others get driven insane by broken sites.
I added this to the bugtracker. I posted above the information on how to enable and keep this setting in your configuration. The security problem is not the rewrite engine itself (even if wrong rewrite rules may cause different problems too), so what we did is not disabling rewrite in the first line, the problem is that the rewrite engine is coupled to the FileInfo option and fileinfo allows also to enable scripting in websites were scripting is disallowed by e.g. adding AddType.... statements or filters to a .htaccess file. For more information, take a look here what fileinfo enables: http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride (as a personal side note, the apache documentation does not even mention that mod_rewrite depends on fileinfo) There is no real solution for this so I will enable overriding of FileInfo again by default and write a note in the documentation that this will impose the risk that poeple with websites without scripting rights can enable them theirself by .htaccess file if the default configuration is not changed. Later version it might be an option to add a field in the site settings to set the override options individually per site.
Thank you very much, was told in an earlier post that this couldnt be done when I asked where the default file was.... Code: No, that's not possible. __________________ Falko wink wink
so the safest solution is the one posted in reply #21, right? http://www.howtoforge.com/forums/showpost.php?p=183193&postcount=21 no other chance to enable only mod_rewrite and nothing else? I guess that is a shortcoming of apache2 then. will alter my masterfiles then. btw. if I change this file /usr/local/ispconfig/server/conf/vhost.conf.master and then go, make a small change in a website and save it will this vhost.conf.master be automatically applied? to the site I jsut saved?
don't understand this. I changed what was psoted above by till, still if one of my wordpress sites tris to use mod rewrite, I get a 403 error: and if I check the vhost file: I even added these directives into the apache directives field within ispcfg3 so what am I doing wrong here? all other wordpress sites are fine after the hack described above by till, even without me adding the directives manually... the only difference I can think of is that meanwhile I have upgraded from (within the last week)
Hi Tenaka, Those apache directives didnt work for me either... In the vhost.conf.master, change the lines to: There should be 4 places in vhost.conf.master where you do this. It worked for me on joomla, magento and wordpress. NOTE: when you upgrade ispconfig3, it wipes these settings out so you will either make a backup of your vhost.conf.master, or put them in again and restart apache2.
I hope that you dont have any clients on your server as you now completely opened up your server for manipulations by your clients.
only in their directory structures, which they should have full access to anyway many clients are happy as their sites are working as should. tenaka, this setting is up to you. I have had no issues with it.
No. As this setting allows also the inclusion of other script interpreters and run bash cgi acripts to break out of their directorys and enable all kind of php functions etc.
Ok, back to my question: I did what till suggested above, edited the masterfile with: and it worked for the last couple of weeks for all wordpress isntallations. Then I upgraded ispcfg3 and yesterday I installed a new wordpress isntallation which is now acting weird, giving those 403 forbidden errrors, so I checked its vhost fiel and it seems ok, see my last psot. what could have gone wrong here?
1) Which version number does ISPConfig show in the interface? 2) Which allow override options are set in the newly created vhost.
1. Powered by ISPConfig 3.0.1.2 2. the vhost contains the following: <Directory /var/www/mydomain> AllowOverride None Order Deny, Allow Deny from All </Directory> then comes the actual Virtualhost directive aka <VirtualHost *.80> ... ... <Directory /var/www/mydomain/web> Options FollowSymlinks Allowoverride Indexes, AuthConfig Limit Fileinfo Order allow, deny Allow from all </Directory> should be working, right? btw. there might be spelling msitakes above, as I couldn't cut and paste, I had to write it manually...
1) Then you dont have the latest version installed. Please install the latest update again and run this command before you do the update: rm -f /tmp/ISPConfig* to remove all old copies of installation files in the /tmp directory. 2) The vhost ino looks fine. But there are two places withe the allowoverride, make sure that both look like this.
1. done. says: 3.0.1.3 2. there are two places, one /var/www/mydomain the other one /var/web/client/... and both look the same as above... stil, if I enable mod_rewrite in this vhost by inserting a mod_rewrite directive into an .htaccess file, I get 403 errors, forbidden.
Please compare the vhost file with a working vhost file from another site and also compare the .htaccess file from this vhost with a .htaccess file from a working installation on the same server.
then the tutorial should be updated here - http://www.howtoforge.com/magento-e-commerce-solution-debian-etch step 7.1 are you saying users who have been following this tutorial are vulnerable?
