Bug #1726
closedmod_access/server-error-404H
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.
Updated by Anonymous over 16 years ago
This is an accidental dup of #1727; sorry!
Updated by stbuehler over 16 years ago
- Status changed from New to Fixed
- Resolution set to duplicate
Also available in: Atom