Bug#672333: apache2-mpm-itk: wrong 403 response when requesting .htaccess protected files from a different UserID in a persistent connection
Package: apache2-mpm-itk
Version: 2.2.16-6+squeeze4
Severity: important
This is a known bug that is fixed in testing. The report is primarily
to back the request for including the patch in s-p-u.
The upstream-patch is attached for completeness.
Steps to reproduce:
-------------------
useradd user1
useradd user2
cat >> /etc/hosts <<EOF
127.0.0.1 itk1.local
127.0.0.1 itk2.local
EOF
cat > /etc/apache2/sites-enabled/itk1 <<EOF
<VirtualHost *:80>
AssignUserID user1 user1
ServerName itk1.local
DocumentRoot /tmp/itk1
</VirtualHost>
EOF
cat > /etc/apache2/sites-enabled/itk2 <<EOF
<VirtualHost *:80>
AssignUserID user2 user2
ServerName itk2.local
DocumentRoot /tmp/itk2
</VirtualHost>
EOF
mkdir /tmp/itk1 /tmp/itk2
cat > /tmp/itk1/index.html <<EOF
<h1>itk1</h1>
<a href="http://itk2.local/";>itk2</a>
EOF
cat > /tmp/itk2/index.html <<EOF
<h1>itk2</h1>
<a href="http://itk1.local/";>itk1</a>
EOF
touch /tmp/itk1/.htaccess
touch /tmp/itk2/.htaccess
chown -R user1:user1 /tmp/itk1
chown -R user2:user2 /tmp/itk1
chmod o-rwx /tmp/itk1/.htaccess
chmod o-rwx /tmp/itk2/.htaccess
apache2ctl restart
$BROWSER http://itk1.local/
Then switch between the two sites by clicking the links a few times
and you will get a wrong 403 response, given that you have "KeepAlive
On" in /etc/apache/apache2.conf and $BROWSER supports persistent
connections.
Upstream-patch:
---------------
Fix an issue where users can sometimes get spurious 403s on persistent
connections (the description in the comments explains the logic).
This would particularly hit people with reverse proxies, since these
have a higher tendency of accessing things from different vhosts in
the same connection.
Index: httpd-2.2.17/server/config.c
===================================================================
--- httpd-2.2.17.orig/server/config.c
+++ httpd-2.2.17/server/config.c
@@ -1840,6 +1840,34 @@ AP_CORE_DECLARE(int) ap_parse_htaccess(a
else {
if (!APR_STATUS_IS_ENOENT(status)
&& !APR_STATUS_IS_ENOTDIR(status)) {
+#ifdef ITK_MPM
+ /*
+ * If we are in a persistent connection, we might end up in a state
+ * where we can no longer read .htaccess files because we have already
+ * setuid(). This can either be because the previous request was for
+ * another vhost (basically the same problem as when setuid() fails in
+ * itk.c), or it can be because a .htaccess file is readable only by
+ * root.
+ *
+ * In any case, we don't want to give out a 403, since the request has
+ * a very real chance of succeeding on a fresh connection (where
+ * presumably uid=0). Thus, we give up serving the request on this
+ * TCP connection, and do a hard close of the socket. As long as we're
+ * in a persistent connection (and there _should_ not be a way this
+ * would happen on the first request in a connection, save for subrequests,
+ * which we special-case), this is allowed, as it is what happens on
+ * a timeout. The browser will simply open a new connection and try
+ * again (there's of course a performance hit, though, both due to
+ * the new connection setup and the fork() of a new server child).
+ */
+ if (r->main == NULL && getuid() != 0) {
+ ap_log_rerror(APLOG_MARK, APLOG_WARNING, status, r,
+ "Couldn't read %s, closing connection.",
+ filename);
+ ap_lingering_close(r->connection);
+ exit(0);
+ }
+#endif
ap_log_rerror(APLOG_MARK, APLOG_CRIT, status, r,
"%s pcfg_openfile: unable to check htaccess file, "
"ensure it is readable",
-- System Information:
Debian Release: 6.0.4
APT prefers stable
APT policy: (700, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages apache2-mpm-itk depends on:
ii apache2.2-bin 2.2.16-6+squeeze4 Apache HTTP Server common binary f
ii apache2.2-common 2.2.16-6+squeeze4 Apache HTTP Server common files
apache2-mpm-itk recommends no packages.
apache2-mpm-itk suggests no packages.
-- no debconf information
Reply to: