Package: apache Version: 1.3.34-4.1 Severity: normal
Hello, after upgrading from Sarge to Etch I found following apache configuration directives to have a bad sideffect: <Location /> <LimitExcept GET POST HEAD> Order Allow,Deny Deny from all Satisfy all </LimitExcept> </Location> FYI this config was the last in my conf.d directory as suggested by http://httpd.apache.org/docs/1.3/sections.html The idea behind this directives is to globally disallow any request which is not POST, GET or HEAD. AFAIK this worked fine under Debian Sarge. Under Debian Etch this ignores all directives Order, Allow and Deny, even in .htaccess. This also affects access control using Oder, Allow and Deny in File-Sections which for instance disallow access to .htaccess files, such that .htaccess files get publicly accessible. After removing these config everything worked fine again. However Apache now answers all HTTP commands, not only GET, POST and HEAD, which can be considered a lowered security on my server. How to reproduce this problem (I did not test it on a fresh install): Use the default install of Debian Etch with mod_userdir active. Then as some user (non-root) do: mkdir public_html cd public_html cat >>.htaccess <<EOF Order allow,deny Deny from all EOF lynx "http://127.0.0.1/~$USER/.htaccess" Access will be denied as expected. As root create file /etc/apache/conf.d/test.conf with following contents: ---------------------- <Location /> <LimitExcept GET POST HEAD> Order Allow,Deny Deny from all Satisfy all </LimitExcept> </Location> ---------------------- Reload Apache. Try to access the .htaccess file again (as above). Under Sarge access still is denied (I think). Under Etch the contents of the .htaccess file is presented to your browser now. You can revert to the correct behavior by removing /etc/apache/conf.d/test.conf and reloading Apache. Notes: Accessing .htaccess files publicly is not the only thing affected. When the Location+LimitExcept section is present, access control through .htaccess does no more work. So in the example above you would be able to access all files in public_html even that .htaccess shall deny access. Note that "Require" is not affected, only "Order, Allow, Deny". Perhaps there are even more sideeffects I did not notice. Unfortunately this problem was discovered on my last machine I upgraded to Etch. Only this machine had the problematic setup. I am not sure the last version of Sarge worked as intended before my upgrade, but I am pretty sure elder versions of Sarge worked as I usually test the .htaccess limitations. ;) However I currently have no more Sarge running to cross-check. Perhaps this behavior change is intended, however I consider this problem to be very weird. So I consider it a bug as LimitExcept shall not affect access control of *other* HTTP methods. I was unable to find any similar bug in the Debian Bug database. Perhaps it's a mod_access bug. However LimitExcept and Location are in Apache core and mod_access is in package apache-common. -Tino -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages apache depends on: ii apache-common 1.3.34-4.1 support files for all Apache webse ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libdb4.4 4.4.20-8 Berkeley v4.4 Database Libraries [ ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii libmagic1 4.17-5etch2 File type determination library us ii logrotate 3.7.1-3 Log rotation utility ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip ii mime-support 3.39-1 MIME files 'mime.types' & 'mailcap ii perl 5.8.8-7 Larry Wall's Practical Extraction apache recommends no packages. -- debconf information: * apache/server-name: hydra.geht.net * apache/document-root: /var/www * apache/server-port: 80 * apache/enable-suexec: false * apache/init: true * apache/server-admin: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]