I'm assuming if a command fails, apache will not start. Which is what should happen. If the module mod_access.c is not loaded... I don't want to be running my apache! I don't want it to go chugging allong! <Directory /> Options -All -Multiviews AllowOverride None <IfModule mod_access.c> Order deny,allow Deny from all </IfModule> </Directory> Another thing... If php isn't working, the source code should not be shown. many poor programers (ahhem, mediawiki, ahhem) store passwords as plain text in a php file that is protected by a die() command at the top! When my php wasn't working, my apache still started like a champ!! but it was leaking sensitive information!!!! I was leaking my passwords!!!!! I feel so violated!!!!
mr_bones_: there's a apache-herd, please assign all apache bugs there
I know that there is the Appache2.conf file that turns on and off modules.. What i'm most worried about is: apache still running after finding a syntax error in the config (it should die) and what happens when scripting modules arn't loaded.. but people have written poor code that stores passwords in plaintext in a script protected with die() can we add few lines like: hidefiles (like how everything .ht is hidden) *.php <IfModule php4> defaultfile= default files with index.php in it hidefiles -*.php <IfModule> or if there is an <IfNotModule> or an <else> This may be upstream, or it may be something we can fix. I know that this is a bug, because things should be locked down sanely by default.
For the PHP files, the behaviour you are suggesting would be similar to the way that IIS 6 works on Windows 2003 server. I think we can do something about this. But we need time to test it first. However, we recommend that you make your mod_access changes to your local copy. We won't be incorporating them into our default Apache configuration files at this time. Best regards, Stu
Ok, i got a few ideas from talking with other people 1. doc root should not have php enabled, and it should not serve php files by deafult, except where sepcifically told to (somebody knows what they are doing) 2. users should be encouraged to alias a directory to their scripting stuff, that is outside of their docroot 3. Apache should die on any error in it's config file. 4. We can use <IfModules> securely.. just enclose everything within the important ones! 5. The negative of IfModule is IfModule !mod_name.c
here is some more info from chipig on #apache, basically if we want anything to be conditional on mod_php.. on apache2.. it isn't completely obvious. we must do the <IfModule sapi_apache2.c> conditional code here </IfModule> ****** <MrDarkUser> i tried doing something with <IfDefine !PHP4> as well.. but that didn't do anything <chipig> <IfModule sapi_apache2.c> <MrDarkUser> the stuff works when it's not contained in <IfModule mod_php4.c> ...blah </IfModule> <chipig> is this apache 2 or apache 1.3? <MrDarkUser> chipig: apache2, gentoo <chipig> right <chipig> try <IfModule sapi_apache2.c> <chipig> instead of mod_php4.c <naknomik> <IfModule !mod_php4.c> <MrDarkUser> fajita: sapi_apache2.c <fajita> MrDarkUser: sorry... <naknomik> that's what I have in my config. <MrDarkUser> fajita: sapi_apache2 <fajita> MrDarkUser: huh? <chipig> fajita: sapi_apache2.c is the name of the source file for the Apache 2.0 SAPI for PHP. <fajita> OK, chipig. <chipig> fajita: sapi_apache2.c =~ s/PHP/mod_php/ <fajita> OK, chipig <MrDarkUser> naknomik: well.. i want it to do stuff only if php is installed <chipig> fajita: sapi_apache2.c? <fajita> i heard sapi_apache2.c was the name of the source file for the Apache 2.0 SAPI for mod_php. <MrDarkUser> now if i say sapi_apache2.c what happens <MrDarkUser> yay.. nothing <chipig> MrDarkUser: i blame PHP for this part, but, anyways, the IfModule> block is based on the *source* filename that the module is compiled into. <naknomik> <ifmodule mod_php4.c> your settings here </ifmodule> chii chipig <chipig> mod_php4 is the name of the SAPI for PHP in apache 1.3 <MrDarkUser> chipig: I'm going to try that right now! <chipig> mod_php4.c is the name of the SAPI for PHP in apache 1.3 <chipig> sapi_apache2.c is the name of this file for the Apache 2.0 SAPI for mod_php
<IfModule !sapi_apache2.c> <Files ~ '\.php$'> Order allow,deny Deny from all Allow from none </Files> <Files ~ '\.phps'> Order deny,allow Allow from all </Files> </IfModule>
this here has a piece of code for inclusion in the apache config file, it won't allow php sources to show... very important for rinkydinky webapp software I hope webapps@gentoo.org is a real email address... I have no idea where the list of valid projects are... And, in general IfModules should be used in a way that unsafe features do not get used... not, add a module that does secuirty stuff... and not complain if it doesn't work. The apache config should probably be split up like debian's config... except work out of the box... (stupid debian apache install didn't work)
is this still an issue with the new ebuilds?
I just checked the default config. The mod_access failing should no longer be an issue - the Allow/Deny lines aren't wrapped in an IfModule. The mod_php failing could be an issue still, because of the default DirectoryIndex: DirectoryIndex index.html index.html.var index.php index.php3 index.shtml index.cgi index.pl index.htm Default.htm default.htm If the php module isn't loaded, and a index.php file exists and index.html doesn't, then the source of the index.php will be displayed. Though if index.php is removed from DirectoryIndex, and mod_php isn't enabled, you get a listing of all files in the directory due to Indexes being on by default - which is the same as upstream's default configuration. This is a sticky issue, and there really is no right way (that I can see) to do this.
Hows about this: DirectoryIndex index.html index.html.var Which is the same as upstream? It has the added benefit of not exposing any sources (PHP, mod_perl, etc.), but also has the drawback where the user will have to add any other index docs themselves - not an issue, imo ;-) I highly disagree with adding the kitchen sink to DirectoryIndex, or any other config file/directive, as it causes situations like this..
i'd welcome that
Are there any objections to taking this path (dropping DirectoryIndex to "index.html index.html.var")? Speek now, or forever hold your peas.
I'm all for changing DirectoryIndex to just the very basic.
fixed in cvs --- 1.3/conf/httpd.conf 4 Feb 2005 13:48:31 -0000 1.2 +++ 1.3/conf/httpd.conf 10 Feb 2005 09:04:55 -0000 @@ -464,7 +464,7 @@ # directory index. Separate multiple entries with spaces. # <IfModule mod_dir.c> - DirectoryIndex index.html index.php index.php3 index.shtml index.cgi index.pl index.htm Default.htm default.htm + DirectoryIndex index.html </IfModule> # --- 2.0/conf/httpd.conf 4 Feb 2005 13:48:31 -0000 1.3 +++ 2.0/conf/httpd.conf 10 Feb 2005 09:04:56 -0000 @@ -461,7 +461,7 @@ # negotiated documents. The MultiViews Option can be used for the # same purpose, but it is much slower. # -DirectoryIndex index.html index.html.var index.php index.php3 index.shtml index.cgi index.pl index.htm Default.htm default.htm +DirectoryIndex index.html index.html.var # # AccessFileName: The name of the file to look for in each directory
Hi, Sorry, your change a) breaks mod_php support in an important way, and b) doesn't fix this bug either. Aaron Peterson's suggested change (comment #6) would be a better solution. Best regards, Stu
yep.. as we discussed it on irc i realized, sorry for that
Hi Stuart :) Although the config fragment in #6 fixes the issue for php, what about all the other web scripting/application server-like modules (mod_perl, mod_python, to name two)? And what about people using non-standard extensions? I've seen no end of people using .html, and even .app, to try and disguise the fact that php was serving pages. Also, are going to build up a blacklist, so to speak, of files to block if mod_xxx isn't loaded? Or are we just going to treat php as a special case? I If we do go with the former solution, I can see it turning into a real mess, and the latter just doesn't feel 'right'. Just my opinion,
Hi Stuart :) Although the config fragment in #6 fixes the issue for php, what about all the other web scripting/application server-like modules (mod_perl, mod_python, to name two)? And what about people using non-standard extensions? I've seen no end of people using .html, and even .app, to try and disguise the fact that php was serving pages. Also, are going to build up a blacklist, so to speak, of files to block if mod_xxx isn't loaded? Or are we just going to treat php as a special case? I If we do go with the former solution, I can see it turning into a real mess, and the latter just doesn't feel 'right'. Just my opinion, £0.02. ;)
i totally agree with you beu, i had a 2-minute-discussion about this with stuart as i resolved the bug and imo this should be up to the user. we provide him with good default (mainly upstream) config files, but we cannot take care of every single case where a user might fsck up his installation *throwing another cent inot the kitty*
Hi Beu, As I explained to Hollow this morning, editing the DirectoryIndex doesn't fix a thing. That should be left the way it is, unless someone knows how the mod_php.conf file can successfully add .php back into the list. Why force all our users to edit part by hand, when there's nothing wrong with us having index.php in that list by default? If you're going to fix this bug, you *have* to do something like the configuration suggested in comment #6. And if it's done for PHP, it would make sense to do it for Perl, Python and Ruby too. We only have to worry about the file extensions that our mod_php.conf, mod_python.conf et al enable. People using non-standard extensions with Gentoo are enabling those extensions by hand; that makes closing this hole their problem. Hope that helps, Stu
Heya Stuart, I don't necessarily disagree with the resolution in comment #6, or with what you (Stuart :) said in comment #19 regarding supporting only Gentoo-supplied module magic (totally agree with the Gentoo-suplied part) - I'm just trying to see if any alternate solutions exist, or whether any of these would cause problems down the line.. :-) Seeing as we would only require a <Files> block per-modle (fex, "<Files ~ "\.(php|php4|php5|...)"> ...", that wouldn't be a problem (imo), but consider the php case where we would need like 5 <IfModule> blocks for each of the apache SAPI's - and that doesn't even include the cgi SAPI which, we of course can't detect because it's being run via the cgi-script handler (this also includes any cgi - beit python, perl or whatever - that is installed by ebuilds and run's under said handler.. I guess this point only applies if we actually _have_ packages that install scripts outside of a ScriptAlias'd directory ;) Are we really going to leave the barn door half open (or 1/3 if only php-cgi is affected :) ?
The code from comment #6 should be added to the configuration of mod_php - there should not be any .php files in the webroot if the user hasn't installed mod_php. If the user puts .php files in the webroot without installing mod_php, that's his own fault if his configuration leaks. With the code in the module configuration, but not in the IfDefine block, the configuration would always be in place as it's included directly. So if php isn't loaded, then .php files are blocked, if it is loaded, then .php files aren't blocked. Re: DirectoryIndex. Clean and simple is good. If the user wants to add more to it, let them. mod_php can either put a message saying the user should add index.php to DirectoryIndex, or put some sed-fu in pkg_config or pkg_postinst to put it there for them. mod_php is not a default part of apache, there shouldn't be anything enabled by default that's not installed by apache. Imagine the confusion of the user who doesn't want mod_php on his system, has never installed it on his machine, but there are references to it in the default configuration. Now, on the other hand, if we add support to the apache ebuild for including various modules based on use flags (i.e. the PDEPEND="php? ( dev-php/mod_php )" that was in the ebuild for a short time) then we should also make use of those USE flags doing sed-fu on the configuration to add reasonable entries to DirectoryIndex based on what other modules are installed. I'm personally for adding a php USE-flag back to apache (as well as many others), but I don't think many others agree with me there. Other thoughts?
I don't see the sense of adding the snippet in comment #6 to the mod_php.conf. If you're going to fix this bug, this should be added to httpd.conf. Otherwise, just mark the bug as WONTFIX and have done with it. Whether you include comment #6 or not, I'm opposed to removing index.php from DirectoryIndex. If you do that, you stop mod_php working out of the box. There seems to be no benefit to anyone in that change. Best regards, Stu
Regarding the DirectoryIndex ... how about having the apache eclass provide a function which mod_php et al could call during pkg_postinst() to add entries? That would keep everyone happy, no?
The sense in adding the code from comment # 6 is this: This problem only occurs if there are .php file in the webroot, and php isn't enabled. Users shouldn't install .php files without installing and enabling mod_php. So if mod_php isn't installed, then this is a non-issue (no .php files = non-issue). If they do install .php files without mod_php installed, that's thier own problem. After mod_php is installed though, users expect .php files to either be executed or blocked. The code from comment #6 does that. So that functionality should be put in mod_php.conf, but outside the IfDefine PHP4 block, so it's not conditional on whether PHP4 is set or not - the same effect as having it in httpd.conf, except that it's not there is mod_php isn't installed. Regarding DirectoryIndex changes causing mod_php to not work out of the box: It doesn't work out of the box anyways, users have to add -D PHP4 to thier configuration. However, I do think a helper function that modules could call to modify the DirectoryIndex could be created.
Created attachment 51100 [details, diff] Patch to add a helper function the apache-module.eclass Here's a patch that needs some testing, to add a helper function to the eclass. For modules that completely use the eclass, you can simply add: APACHE2_MOD_DIRINDEX="index.ext" For modules that don't use the eclass, you can add to pkg_postinst or pkg_config: apache-module_add_directoryindex index.ext It supports multiple files to add to Directory Index, and puts a nice comment in the httpd.conf stating what it did: # DirectoryIndex index.html index.html.var # index.layout index.layout2 automaticly added by mod_layout-4.0.1a-r1 DirectoryIndex index.html index.html.var index.layout index.layout2 (mod_layout doesn't and won't actually add a index, I was just using it for testing). Comments and suggestions?
I'm opposed to my config files being changed directly by automated processes. Doing it during the src_install phase, so I can approve the change with etc-update is fine, but config files should not be changed in any other fashion. Your code wouldn't work for me anyway, as I keep DirectoryIndex just having .html, and enable .php or others on a per-vhost basis (some of my vhosts do use the .html served via PHP trick as well, at the request of customers).
If we modify the httpd.conf in the src_install stage multiple packages would own httpd.conf, and that breaks collision-protect. How about sed-fu live config, but in pkg_config instead of pkg_postinst? So the user would have to run ebuild /var/db/pkg/${PF}/${PF}.ebuild config... Though if we are going to do that, might as well just have the user modify httpd.conf directly, as it would still require an einfo with instructions. Though there is an einfo telling the user to add -D PHP4 to thier /etc/conf.d/apache already. What about patching mod_dir.c to add a new directive AddDirectoryIndex which would incrementally add more files to the DirectoryIndex? cons of this, other then some module configurations would no longer be portable to other distros?
If we're going the route of changing upstream, I'd really like it to work like the 'Options' directive. eg: DirectoryIndex index.html index.shtml <IfDefined PHP4> DirectoryIndex +index.php </IfDefined PHP4> Would upstream find this more acceptable?
I originally thought that as well, using + to add files. But there's a corner case: filenames can have + in them. As to whether upstream would take this, I have no idea. chipig: since you are upstream, how would they take such a patch?
re: #29, I do not like changing the behavoir of DirectoryIndex. While '+' or '-' in file names might be rare, it could still break end users configurations, and therefore is not acceptable. A new directive would have the best chance of getting accepted. Even then... I am not sure what other developers would think of it. People are more receptive to patches, not idle talk. Get a working patch, and I think there is a good chance.
Created attachment 51118 [details, diff] Implement AddDirectoryIndex and RemoveDirectoryIndex After many hours of refreshing my C skills and learning the apache API, I have managed to create a working patch that adds the following directives: AddDirectoryIndex filename [filename ...] Adds a filename to the DirectoryIndex list RemoveDirectoryIndex filename [filename ...] Removes a filename from the DirectoryIndex list It needs testing as I'm not very confident in my C skills. If it seems okay with everyone who tests it, I will add it to our apache patchset, and push it upstream as well.
re #24: of course users can (and will) install .php files without having php installed, and without having a mod_php.conf present on the filesystem. Apologies, but I'm not convinced by that argument ;-) We can do sed-fu on the live filesystem from pkg_postinst(), and the mod_* packages won't end up owning the apache config file as a result. Requiring users to run pkg_config() is evil, and should be avoided in all cases. Why? Because the current Portage does not guarantee that the user will ever see any message telling them to run /var/blah/blah.ebuild config. Some users install mod_php explicitly, but some users install (say) squirrelmail explicitly, and mod_php gets installed as a DEPEND. In the second case, any instructions output from the mod_php ebuild could have scrolled by without the user being present to see them. Best regards, Stu
Are there any objections to including my AddDirectoryIndex/RemoveDirectoryIndex patch? If not, then that's out solution... mod_php.conf and other modules that need something in DirectoryIndex will just add an AddDirectoryIndex directive to their module configuration.
Created attachment 51715 [details, diff] Patch for 1.3.33 implementing AddDirectoryIndex/RemoveDirectoryIndex Patch that implements the same for 1.3.33 as well.
Patches added to gentoo-apache tarballs for 2.0.52-r3 and 1.3.33-r1. This issue is fixed on the apache end of things. The php herd can add the code from comment 6 to thier module configuration if they wish (I personally think they should), and should add an AddDirectoryIndex directive to their module configuration.
Hi, Please don't mark those versions of Apache as 'stable' until the PHP Herd has updated their ebuilds. Best regards, Stu
Adding this as a blocker to making apache stable (meta bug 76457) (though we will continue to move from hard mask to ~arch) Assigning to php herd, as it's mod_php's config that needs to be fixed, apache's part is fixed in regards to this. This should be done as part of updating/reviewing the mod_php ebuilds in regards to bug 77556.
Created attachment 66529 [details] Disable accessing PHP files if mod_php not loaded
Hi, I've added an attachment which will prevent access to PHP files if mod_php is not loaded. Could someone from the Apache herd please commit this? Then we can close this bug. Ta, Stu
As noted in my comment above, any patch to globally disable .php files if mod_php isn't enabled should be installed by mod_php and NOT by apache. Perhaps I haven't made my logic clear. If a user puts .php files in their document root without installing mod_php first, then we are to assume they want those .php files available for viewing the source, and not executed. If a user installs mod_php, then installs .php filess in the document root, then those files should be executed. If after a user has installed mod_php and .php files, for some reason mod_php becomes disables, then those .php files should not be accessible. You patch makes those files non-accessible, a situation which is only desired when mod_php has been previously installed at some point. I am against the inclusion of this patch in apache. I am for the inclusion of this patch in mod_php. Apache herd members: are any of you (other then stuart) for including this patch? Does anyone have any other arguments about this patch? If not, then I am going to close this as WONTFIX in 24 hours.
(In reply to comment #40) > I am against the inclusion of this patch in apache. I am for the inclusion of > this patch in mod_php. Same here. > Apache herd members: are any of you (other then stuart) for including this > patch? Does anyone have any other arguments about this patch? Not really an apache herd member, but this breaks mod_suphp (needs manual <IfDefine !SUPHP> tweak, while so far it works really out of the box) and will equally break any other CGI implementation in portage. Just my $0.02 ;)
Gave over the 24 hours that I said I would before. You can add this patch to mod_php if you wish, but it's not going into apache directly.
FYI, If anyone is wondering where this stands, I attempted to suggest this to the PHP group (Bug #127645) but it was pretty much shot down.
