Project

General

Profile

Bug #1726

mod_access/server-error-404H

Added by chris@arachsys.com over 11 years ago. Updated over 11 years ago.

Status:
Fixed
Priority:
High
Assignee:
-
Category:
core
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

The behaviour of url.access-deny in a `$HTTPurl conditional has changed between lighttpd 1.4.18 and 1.4.19 in a way that prevents @url.access-deny being used to protect areas of a website with files handled by a @server-error-404` handler outside the protected area. The simplest test case I've been able to cook up is as follows:


server.bind = "127.0.0.1" 
server.port = 8080
server.errorlog = "/dev/null" 
server.modules = (
  "mod_access",
)

server.document-root = "/tmp/www" 
server.error-handler-404 = "/index.html" 
$HTTP["url"] =~ "^/forbidden/" {
    url.access-deny = ("")
}

where /tmp/www/forbidden is empty and /tmp/www/index.html exists. On 1.4.18, this will refuse to return copies of /index.html for URLs in /forbidden/, whereas on 1.4.19, it allows them to be served from /index.html. Lighttpd seems to have started checking the URL of the handler instead of the URL of the original request. (I've also seen breakage the other way around, where the handler was in an otherwise forbidden directory, and stopped working in the change from 1.4.18 -> 1.4.19.)

This is potentially quite a nasty regression as, following an upgrade, people may not immediately notice that protected directories covered by a server-error-404 handler with wider scope are suddenly open when they should be forbidden.

I bisected the changesets between 1.4.18 and 1.4.19 to pinpoint where this behaviour first appeared. The change between subversion revisions 2079 and 2080 (where the cond_cache reset moves from connections.c to response.c) is the culprit: revision 2079 behaves correctly whereas revision 2080 allows the file through. However, I'm afraid I'm not familiar enough with the lighttpd core to supply a patch for this which I'm confident doesn't break any later changes.

#1

Updated by Anonymous over 11 years ago

This is an accidental dup of #1727; sorry!

#2

Updated by stbuehler over 11 years ago

  • Status changed from New to Fixed
  • Resolution set to duplicate

Also available in: Atom