Project

General

Profile

Actions

Bug #3167

closed

Lighttpd, rewrite and a new access-deny behavior

Added by admonaut 12 days ago. Updated 10 days ago.

Status:
Invalid
Priority:
Normal
Category:
mod_access
Target version:
-
ASK QUESTIONS IN Forums:
No

Description

I protect a directory with access-deny in the Lighttpd configuration:

$HTTP["url"] =~ "^/config/.*" {
url.access-deny = ("")
}

In the configuration, for example, there is a global rewrite for the statistics service Matomo:

url.rewrite-if-not-file = (
"" => "/index.php${url.path}${qsa}"
)

Originally (Version 1.4.55, Ubuntu 20.04 LTS), the "access-deny" for the "/config/" directory worked without any problems. Now (Version 1.4.63, Ubuntu 22.04 LTS), in combination with the global rewrite, the web server ignores the "access-deny" and the data is visible from the outside, or you can access it via the Internet access it.

If I remove the global rewrite again, the typical 403 message appears. If I add the global rewrite again, the lighttpd ignores the "access-deny" again.

This behavior is not expected and it creates, in my opinion, an unconscious security hole . I noticed it with the last Matomo update because the system check from the Matomo update reported it as a serious error. Suddenly all could access the /config/ and /tmp/ directories from outside.

We had upgraded from Ubuntu 20.04 LTS to 22.04 LTS and since then the behavior of "access-deny" in Lighttpd must have changed. I was also able to reproduce it on a test server with the same reaction.

"access-deny" shouldn't just follow the rewrite, it should always be valid.

You can find exact details on: https://administrator.pro/en/lighttpd-rewrite-and-a-new-access-deny-behavior-3552309279.html

greeting
Frank


Files

404_Bildschirmfoto vom 2022-08-06 17-16-14.png (9.98 KB) 404_Bildschirmfoto vom 2022-08-06 17-16-14.png With error-handler-404 and the file 404 admonaut, 2022-08-06 16:12
403_Bildschirmfoto vom 2022-08-06 17-14-50.png (12.9 KB) 403_Bildschirmfoto vom 2022-08-06 17-14-50.png Without error-handler-404 admonaut, 2022-08-06 16:12
rewrite_Bildschirmfoto vom 2022-08-06 17-15-45.png (26.9 KB) rewrite_Bildschirmfoto vom 2022-08-06 17-15-45.png With error-handler-404 and deleted file 404 admonaut, 2022-08-06 16:12
Actions #1

Updated by gstrauss 11 days ago

  • Status changed from New to Missing Feedback

Please see How to get support and follow the instructions there.

I created a basic lighttpd.conf and was unable to reproduce the issue as you described. (I do not use Ubuntu or Matomo)

server.modules += ("mod_access", "mod_rewrite", "mod_cgi")
server.port = 8080  #  (testing as non-root on port 8080)

server.document-root = "/dev/shm" 

$HTTP["url"] =~ "^/config/.*" {
  url.access-deny = ("")
}

url.rewrite-if-not-file = (
  "" => "/index.php${url.path}${qsa}" 
)

cgi.assign = ( ".php" => "/usr/bin/php-cgi" )

and created trivial files to protect:

mkdir /dev/shm/config
echo secret > /dev/shm/config/secret.txt

I was denied access to http://localhost:8080/config/secret.txt and http://localhost:8080/config/non-existent.txt
Access to a non-existent file elsewhere was rewritten to index.php as expected (http://localhost:8080/non-existent.txt)


Regarding your post title: "Lighttpd, rewrite and a new access-deny behavior":

There is nothing "new" about Ubuntu, which incorrectly thinks "neglect" is equivalent to "maintenance". Ubuntu often provides outdated software. lighttpd 1.4.55 is old, released over 2 1/2 years ago. The latest lighttpd release is lighttpd 1.4.65 (and lighttpd 1.4.66 is likely to be released next week.)

Actions #2

Updated by gstrauss 11 days ago

Your post at https://administrator.pro/en/lighttpd-rewrite-and-a-new-access-deny-behavior-3552309279.html is longer, but confusing.

Only an error in PHP needs to occur and the files in the protected directories are readable. With text files the content is immediately visible.

PHP is running outside (separately from) lighttpd. How is an error in PHP exposing text files?

The problem can't be solved by Lighttpd webserver at the moment.

Even if there is an issue in lighttpd (to be determined), your statement is possibly untrue. Many things can be worked around using lighttpd mod_magnet and some custom lua script.

Actions #3

Updated by admonaut 11 days ago

Why was the ticket closed? The answers here are completely confused. Why does it say "Missing Feedback". How should I respond if the ticket has been closed. I just want to help to find the error, after a short test you can hardly close the ticket immediately just because you couldn't reproduce it immediately. I've been using lighttpd for over 20 years and didn't expect such hostile feedback.

Please see How to get support and follow the instructions there.

I took that from my point of view. I have given the exact versions and also the system on which the web server is running. The configuration that is required to understand the error was also given and I cannot and do not want to publish more here. We are a website with millions of views. I can still reproduce the error on myself. With which version did you test it? As stated above, our version is 1.4.63. Besides, what's your test worth if you haven't tested it under the same environment. Another reason not to close the ticket under any circumstances.

There is nothing "new" about Ubuntu, which incorrectly thinks "neglect" is equivalent to "maintenance". Ubuntu often provides outdated software. lighttpd 1.4.55 is old, released over 2 1/2 years ago. The latest lighttpd release is lighttpd 1.4.65 (and lighttpd 1.4.66 is likely to be released next week.)

Where did I say that? Maybe read the post properly. I wrote that when you switch from Ubuntu 20.04 LTS to 22.04 LTS, there will of course be a big version jump. Before it worked for us, afterwards it didn't. The only thing that changed in between was the lighttpd version. It was just meant to be a help and an explanation of how the error came about for us. It always worked before with version 1.4.55 and we didn't change the Lighttpd config (we checked it again in our git, where all configs are managed by us). The error exists and is real.

PHP is running outside (separately from) lighttpd. How is an error in PHP exposing text files?

Matomo writes its config files into PHP files. If there is an additional error in the FPM-PHP (config or whatever) caused by a careless admin (yes, there are), then this file can also be displayed as plain text. I have now checked the problem a little deeper, and come to the conclusion that in reality only the contents of the index.php is output and not the real files in the directory. So it only looks like the /config/ directory can be accessed from outside, for example.

Even if there is an issue in lighttpd (to be determined), your statement is possibly untrue. Many things can be worked around using lighttpd mod_magnet and some custom lua script.

I've already found a workaround for me (haproxy) but I would prefer it to work under lighttpd as well.

Please open the ticket again .

Actions #4

Updated by admonaut 11 days ago

I'm trying to continue professionally here and looked at your test above. In your example above, you just forgot to create a real index.php with content as well. If lighttpd doesn't find the index.php then the access-deny protection is working as it should.

However, if the file exists, it always follows the rewrite and the /config/ directory is displayed with the content of the index.php file. But one would have expected a 403 (it was still like that in 1.4.55). Even if the real content of /config/ is not displayed here, test scripts such as those from Matomo do not expect any content here (i.e. a 403). Instead, content is output (that of index.php) and the HTTP code 200 is displayed. This differs the behavior from version 1.4.55 to version 1.4.63. If the /config/ directory was configured with "access-deny", lighttpd should continue to respond with 403 even with a global rewrite.

The question of whether the real directory /config/ can now be read by a config or some other error (and it does not follow index.php under unspecified conditions) is only theoretical at the moment. As already mentioned above: If the remote file does not exist at all, the directory is protected by "access-deny".

So far I haven't been able to produce a real security breach. I also crashed the php-fpm interpreter and the "access-deny" protection works again immediately. So it all looks like it's not a security breach. The fact remains that a directory that should actually show a HTTP-403 through "access-deny" shows a HTTP-200 OK through the rewrite and thus misleads many check scripts.

I have updated the text on our website

Actions #5

Updated by gstrauss 11 days ago

  • Status changed from Missing Feedback to Need Feedback

I think you need to slow down and review what I posted.

You received a response from one of the lighttpd developers the same day you posted your problem. The response included a test configuration which did not reproduce the error. I tested with the latest lighttpd version, which I thought was implied by my stating the current release of lighttpd is lighttpd 1.4.65 and that Ubuntu is usually outdated.

How should I respond if the ticket has been closed.

By providing more information.

I meant to choose "Need Feedback" instead of "Missing Feedback". My mistake. In either case, a reasonable response from you would be to provide more information. If your blow-up is the result of my choosing "Missing Feedback", I think you should evaluate why you posted a screed instead of posting simple questions in a response, e.g. "Why was this issue marked Missing Feedback? What additional information can I provide?"

I have given the exact versions and also the system on which the web server is running.

That information was sufficient for me to state that you are not running the latest lighttpd release and for me to respond that I do not have your environment. Do you dispute either of those factual statements? If so, why?

The configuration that is required to understand the error was also given

No. No it absolutely was not given. You provided two very small pieces of your config, and my response demonstrated that was insufficient to reproduce the issue. I provided the configuration that I used to verify that mod_access and mod_rewrite were working as intended in a simple test case. Are you able to reproduce your issue in your environment using the very simple (and complete) lighttpd.conf I provided?

and I cannot and do not want to publish more here.

That is your prerogative. I think that I quite clearly both stated and demonstrated that I could not reproduce the issue with the limited information you provided.

I apologize that you took my response as hostile. I did not dismiss it out hand and I provided a sample config that I used to demonstrate that a simple test case works as intended for me in my environment.

Besides, what's your test worth if you haven't tested it under the same environment. Another reason not to close the ticket under any circumstances.

I develop and maintain lighttpd. I do not maintain any packages in Ubuntu.

There is nothing "new" about Ubuntu, which incorrectly thinks "neglect" is equivalent to "maintenance". Ubuntu often provides outdated software. lighttpd 1.4.55 is old, released over 2 1/2 years ago. The latest lighttpd release is lighttpd 1.4.65 (and lighttpd 1.4.66 is likely to be released next week.)

Where did I say that?

The answer is in the sentence immediately prior. The full quote:

Regarding your post title: "Lighttpd, rewrite and a new access-deny behavior":
There is nothing "new" about Ubuntu, which incorrectly thinks "neglect" is equivalent to "maintenance". Ubuntu often provides outdated software. lighttpd 1.4.55 is old, released over 2 1/2 years ago. The latest lighttpd release is lighttpd 1.4.65 (and lighttpd 1.4.66 is likely to be released next week.)

The "new" in "new access-deny behavior" is indicative of your very narrow view that what you see in front of your eyes is what everyone else sees. That is a narrow view, e.g. Ubuntu-specific, which you did share in the details of your post. If this is indeed an issue with lighttpd (to be determined), then it is not "new" in lighttpd. It might be "new" in "Ubuntu 22.04 LTS". However, this site is the official site for lighttpd, not Ubuntu or any Ubuntu packages. lighttpd 1.4.63 is not "new".

Maybe read the post properly. I wrote that when you switch from Ubuntu 20.04 LTS to 22.04 LTS

If there is a bug in lighttpd, I fix it in lighttpd and release a new official version of lighttpd. That's how we use version numbers. If a package maintainer for your distro backports a patch, hopefully your distro uses version numbers and updates the package version number in the distro. Again, I do not maintain any packages in Ubuntu. I develop and maintain lighttpd, not your distro of choice. There are many tens, possibly hundreds of distros. I do not maintain them.


The problem can't be solved by Lighttpd webserver at the moment.

Even if there is an issue in lighttpd (to be determined), your statement is possibly untrue. Many things can be worked around using lighttpd mod_magnet and some custom lua script.

I've already found a workaround for me (haproxy) but I would prefer it to work under lighttpd as well.

I am glad that you have a workaround. That was not my point. The point I was trying to make is that your phrasing is extreme. You might not yet know of a workaround in lighttpd, but if there is an issue, then I might know of a workaround using mod_magnet, and the workaround might be able to be deployed immediately, before an official patch becomes available. I have previously documented some examples of lighttpd mod_magnet lua security responses. You saying: "I am currently unaware of a workaround in lighttpd" would be more accurate than your more presumptive statement "The problem can't be solved by Lighttpd webserver at the moment."


The error exists and is real.

Maybe so. That is why I wrote:

Even if there is an issue in lighttpd (to be determined), ...

.

Matomo writes its config files into PHP files. If there is an additional error in the FPM-PHP (config or whatever) caused by a careless admin (yes, there are), then this file can also be displayed as plain text. I have now checked the problem a little deeper, and come to the conclusion that in reality only the contents of the index.php is output and not the real files in the directory. So it only looks like the /config/ directory can be accessed from outside, for example.

This sounds to me like a misconfiguration.

You have not shared sufficient parts of your config, so the following is a general statement and might or might not apply to you: If lighttpd is configured to send *.php to PHP-FPM via mod_fastcgi, then lighttpd does so. If PHP-FPM is misconfigured, or the PHP has mistakes and serves plain-text, then that is out of the control of lighttpd. If lighttpd is misconfigured, then, well, lighttpd is misconfigured. Numerous distros include the following in /etc/lighttpd/lighttpd.conf: static-file.exclude-extensions = ( ".php", ".pl", ".fcgi", ".scgi" ) as a safety against lighttpd mod_staticfile serving files with those extensions as static files when an admin has made a mistake configuring lighttpd.

I'm trying to continue professionally here

Next time, maybe omit your complaints and try to politely ask for further assistance along with trying to provide additional information?

In your example above, you just forgot to create a real index.php with content as well. If lighttpd doesn't find the index.php then the access-deny protection is working as it should.

I did not spell out a "Hello World" index.php. I implied it with cgi.assign = ( ".php" => "/usr/bin/perl" ). My Hello World was in Perl. Note: I'm going to correct the example above to point to php-cgi instead.

However, if the file exists, it always follows the rewrite and the /config/ directory is displayed with the content of the index.php file.

That is unclear to me, as I am not familiar with Matomo or your environment.

However, if the file exists, it always follows the rewrite

That is nonsensical to me. If the target uri-path resolves to a resource which is a file, then url.rewrite-if-not-file should not run at all since url.rewrite-if-not-file is applied when the target uri-path is not a file, as is described in the name "url.rewrite-if-not-file".


As I mentioned above, your further (more polite) description of your problem sounds like a misconfiguration.

Please see How to get support and follow the instructions there.

Did you run lighttpd -p -f /etc/lighttpd/lighttpd.conf and have you reviewed your config?

The fact remains that a directory that should actually show a HTTP-403 through "access-deny" shows a HTTP-200 OK through the rewrite and thus misleads many check scripts.

url.rewrite-if-not-file applies to directories. A directory is not a regular file; a directory is a directory. url.rewrite-if-not-file applies to anything that is not a regular file, including directories.

Maybe your lighttpd.conf configures lighttpd mod_indexfile to display index.php, and you have not configured PHP-FPM to handle .php files under /config/ ? That's just a guess since you have not shared any more of your lighttpd.conf.

Maybe your issue could be "solved" with a simpler configuration instead of "^/config/.*":

$HTTP["url"] =~ "^/config/" {
  url.access-deny = ("")
}

Actions #6

Updated by gstrauss 11 days ago

It would be helpful if you could reduce your lighttpd configuration to something smaller that you can share and that also reproduces the issue. Try incrementally removing modules listed in server.modules

See also lighttpd.conf DebugVariables to possibly get some data about which lighttpd.conf conditions and which lighttpd modules are contributing to serving the request which results in the issue. Compare that to requests which do not result in the issue.

Actions #7

Updated by admonaut 11 days ago

Ok, after there were so many misunderstandings here I have now made the effort and set up a VM with Ubuntu and the Lighttpd version 1.4.63. I think I have found the error. Version 1.4.63 is the version that comes with Ubuntu and I can't change that for now. The virtual server now has lighttpd and fpm-php (PHP 8.1) installed in addition to the default Ubuntu, nothing else.
I have reduced the configuration to the most necessary:

server.modules = (
        "mod_indexfile",
        "mod_access",
        "mod_alias",
        "mod_redirect",
        "mod_auth",
        "mod_rewrite",
        "mod_fastcgi" 
)

server.document-root        = "/var/www/html" 
server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
server.errorlog             = "/var/log/lighttpd/error.log" 
server.pid-file             = "/run/lighttpd.pid" 
server.username             = "www-data" 
server.groupname            = "www-data" 
server.port                 = 80

index-file.names            = ( "index.php", "index.html" )
url.access-deny             = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

include_shell "/usr/share/lighttpd/create-mime.conf.pl" 

$HTTP["url"] =~ "^/config/.*" {
  url.access-deny = ("")
}

url.rewrite-if-not-file = (
  "" => "/index.php${url.path}${qsa}" 
)

fastcgi.server += ( ".php" =>
        ((
                "socket" => "/run/php/php8.1-fpm.sock",
                "broken-scriptfilename" => "enable" 
        ))
)

Then I created in /var/www/html/ the directory /config/ and the file index.php (with echo "Hello"; and a phpinfo();).
When I start this configuration, the index.php with "Hello" and the phpinfo() appears in the browser. If I call the directory /config/ or a file behind it, it works as desired and a "403 Forbidden" page appears. If I call any fantasy url e.g. /kedjedej the rewrite takes effect and the index.php is called again. So far so good.

Now I add the following to the configuration (and restart lighttpd):

server.error-handler-404    = "/404.php" 

For this I create a 404.php page with "404 not found page" in the text (for a customized 404-HMTL status page).

If I now call the /config/ directory or a file behind it in the browser, my just created "404 not found page" page appears instead of the "403 Forbidden" page.
Should this be so? In any case, the HTML status 200 is now output, because I did not include a header() in the 404.php page.

If I delete now only the "404.php" file and change nothing in the configuration, now in the browser under the /config/ directory the rewrite index.php is called and displayed. Probably, because now the "rewrite-if-not-file" takes effect (the file was deleted).

Exactly this had happened with us. We had specified via "server.error-handler-404" a file that no longer existed and then the web server triggered the global rewrite and displayed it. That lighttpd uses the "error-handler-404" for a 403 status was not clear to us. Is a bit different than I had suspected at the beginning, but the result was then the said HTTML-200-OK status, which triggered the security warnings e.g. at Matomo. So the question would be:

  • Why is the "error-handler-404" triggered with a 403?
  • Should it be so that the global rewrite is triggered if the "error-handler-404" file does not exist?

I hope I was able to isolate and explain the error better. It was also difficult for me to immediately identify the source of the error.

Actions #8

Updated by gstrauss 10 days ago

  • Status changed from Need Feedback to Invalid
  • Target version deleted (1.4.xx)

Why is the "error-handler-404" triggered with a 403?

That is historical behavior in lighttpd server.error-handler-404 which is documented on Docs_ConfigurationOptions for server.error-handler-404 and also in server.error-handler-404 details. Back in 2016, I created an alternative server.error-handler as an option instead of server.error-handler-404. See Docs_ConfigurationOptions for more details.

Another option since lighttpd 1.4.56 is mod_magnet magnet.attract-response-start-to where you can run a custom error handler lua script directly within lighttpd, and do what you need to do if lighty.r.req_item.http_status == 404 (lighttpd 1.4.65+) (or, in lighttpd 1.4.56 to lighttpd 1.4.65: lighty.r.req_attr["http-status"] == 404 )

Should it be so that the global rewrite is triggered if the "error-handler-404" file does not exist?

The error handling code re-uses lighttpd's regular handling code since lighttpd allows the error handler to be a real file or a virtual file (e.g. fastcgi.server option "check-local" => disable"). Since the error handler might be virtual, the lighttpd base can not easily know whether or not you intended for that error handler to exist or not because the lighttpd error handling code does not know in advance which lighttpd module you intended to handle the error handler uri-path.


As you filed an issue in the lighttpd issue tracker, and the lighttpd issue tracker is for tracking issues in lighttpd (as opposed to end-user support requests), I am marking this issue as Invalid, since lighttpd is working as I expect. The lighttpd Forum is a better place to ask questions.

Actions #9

Updated by gstrauss 10 days ago

If I delete now only the "404.php" file and change nothing in the configuration, now in the browser under the /config/ directory the rewrite index.php is called and displayed. Probably, because now the "rewrite-if-not-file" takes effect (the file was deleted).

Exactly this had happened with us. We had specified via "server.error-handler-404" a file that no longer existed and then the web server triggered the global rewrite and displayed it.

You can protect your global rewrite against some admin mistakes which might expose e.g. /config/ or /tmp/ with the addition of something like

$HTTP["url"] =~ "^(?:/index.php)?/(?:config|tmp)/" {
  url.access-deny = ("")
}

Actions #10

Updated by gstrauss 10 days ago

Forgetting lighttpd for a moment, if a request to /index.php/config/index.php was serving the plaintext file under /config/index.php, then that is an issue with /index.php not knowing what parts of the site to serve and what parts to protect. Bad interactions of PHP with other site policy is a common security problem, and is independent of lighttpd. I don't need url.rewrite-if-not-file = ("" => "/index.php${url.path}${qsa}") or server.error-handler-404 = "/404.php" to directly request https://example.com/index.php/config/index.php

Please retract the incorrect security allegations you made against lighttpd in https://administrator.pro/en/lighttpd-rewrite-and-a-new-access-deny-behavior-3552309279.html.

"The problem can't be solved by Lighttpd webserver at the moment." is demonstrably incorrect.

lighttpd can help protect you from your team's accidental misconfiguration of lighttpd. NB that missing 404.php is independent of the actual security exposure of your site's current /index.php which appears to serve any file under your document root since that /index.php is apparently unaware of other site security policy.

$HTTP["url"] =~ "^(?:/index.php)?/(?:config|tmp)/" {
  url.access-deny = ("")
}

BTW, does a request to https://example.com/index.php/index.php serve a plaintext version of /index.php? Who wrote that /index.php?

Actions #11

Updated by admonaut 10 days ago

if a request to /index.php/config/index.php was serving the plaintext file under /config/index.php, then that is an issue with /index.php ...

You're getting lost there. Have you never seen a PHP server output its source code as plain text instead of parsing it? All it takes is a "buffer overflow" or other security vulnerabilities within PHP. We've seen this happen several times in the last few years. So this has nothing to do with the programming of the index.php or the rest. Matomo writes its config into the /config/ directory and that should be secured and not callable. This is the job of the web server.

I don't need url.rewrite-if-not-file = ("" => "/index.php${url.path}${qsa}") or server.error-handler-404 = "/404.php" to directly request https://example.com/index.php/config/index.php

Of course not. Therefore, one secures these directories with "access-deny". But if, for example, the "error-handler-404" then delivers a 200 HTTPS status instead of a 403, the security tools immediately kick in. In the first moment you think of a security hole - that's what the tools say. Then you realize that it was a rewrite to the index.php. Finally you don't expect the "error-handler" to deliver a directory, which should give a 403 by "access-deny". It just looks wrong if in the url the protected directory responds with HTTPS status 200. The "rewrite-if-not-file" is only there for the program logic and has only by chance a link here.

"The problem can't be solved by Lighttpd webserver at the moment." is demonstrably incorrect.

For us, it looked like this at first. Thanks to no help, we eventually found the error ourselves and also adjusted our texts to it. You were too busy pointing out what we were doing wrong and reacted far too quickly and rashly. Why do you close a ticket after a single unsuccessful test? If someone reports something like that to you, he has a problem after all and should not be treated like a nuisance. We just wanted to help, as we have been using lighttpd for over 20 years and like it. We have over 10 million hits a month and lighttpd does that really well, why should we write false claims here. Sometimes you should look at the problems from the other perspective.

lighttpd can help protect you from your team's accidental misconfiguration of lighttpd. NB that missing 404.php is independent of the actual security exposure of your site's current /index.php which appears to serve any file under your document root since that /index.php is apparently unaware of other site security policy.

We have not misconfigured lighttpd. Since the config: "error-handler-404" is still part of lighttpd, we think it returns a wrong result. So is the error with us, because we use it or with ligttpd who provides it. It is also not our "index.php" but the one of Matomo. In this context there is no security hole. I don't know how you got that idea. You don't know the site security policy of Matomo.

BTW, does a request to https://example.com/index.php/index.php serve a plaintext version of /index.php? Who wrote that /index.php?

No idea what you mean by that. With Matomo, the "index.php" was certainly written by the developers.

Anyway, I took out the "error-handler-404" and now it works again as expected. From our point of view it was a bug, so we entered it that way. Since the post has now been closed again, the topic is also done for us. Maybe it's time to look at other web servers.

Actions #12

Updated by gstrauss 10 days ago

You're getting lost there. Have you never seen a PHP server output its source code as plain text instead of parsing it?

In the past, I have seen many, many, many security issues with PHP code, and I personally avoid PHP and have not used it in many years.

Thanks to no help, we eventually found the error ourselves

Cool. If you'd like to explain my "stupidity" to me, please clarify how the information you provided demonstrated the problem. Quoting from the original post:

I protect a directory with access-deny in the Lighttpd configuration:

$HTTP["url"] =~ "^/config/.*" {
url.access-deny = ("")
}

In the configuration, for example, there is a global rewrite for the statistics service Matomo:

url.rewrite-if-not-file = (
"" => "/index.php${url.path}${qsa}" 
)

Finally you don't expect the "error-handler" to deliver a directory, which should give a 403 by "access-deny". It just looks wrong if in the url the protected directory responds with HTTPS status 200.

As I explained above, I agree that server.error-handler-404 has some surprising behavior, which is why I wrote what I think are better alternatives. At the same time, the behavior of server.error-handler-404 is well-documented, so I do not accept this as an excuse for you, or that it is a bug in lighttpd, since server.error-handler-404 works as documented. Were I to change server.error-handler-404, doing so might break existing usage, and so in 2016 (7 years ago), I wrote alternatives for server.error-handler-404 in lighttpd 1.4.40.

You were too busy pointing out what we were doing wrong and reacted far too quickly and rashly.

Please do point out to me where you think I was wrong. This is a public record. Go ahead. I posted multiple times requesting additional information, and my educated guess was that your issue was a misconfiguration. It turns out your missing target for your configured server.error-handler-404 contributed to your issue, and I think that qualifies as a misconfiguration.

We have not misconfigured lighttpd. Since the config: "error-handler-404" is still part of lighttpd, we think it returns a wrong result.

What you think differs from both the code and the official documentation of how server.error-handler-404 works. That's unfortunate and not ideal, but is not a bug in lighttpd. If the code and the documentation match, then why are you right and the code and documentation are wrong?

If your response is that I should change the behavior of server.error-handler-404, then please re-read my multiple, repeated explanations in the posts above.

If someone reports something like that to you, he has a problem after all and should not be treated like a nuisance.

I do not think you are new to the internet or to open source, but you are very mistaken in that statement. Personally, I try to help people who try to help themselves and to help me to help them. I tend to be rude to people who think they are entitled to support or to my time. Let me be absolutely clear: You are entitled to nothing from me. Get over yourself.

You don't know the site security policy of Matomo.

I never said that I did. In fact, I said the opposite multiple times: that I am unfamiliar with Matomo. I also repeatedly acknowledged that I do not have your environment, and that you shared very limited details of your environment.

Maybe it's time to look at other web servers.

LOL. If you have some self awareness, please consider asking a trusted friend to review both your and my posts with you. Everybody has room for improvement.

Actions #13

Updated by admonaut 10 days ago

I tend to be rude to people who think they are entitled to support or to my time. Let me be absolutely clear: You are entitled to nothing from me. Get over yourself.

This is exactly the kind of answer I expected from you. Thank you

Actions

Also available in: Atom