Lighttpd

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.)

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 = ("")
}

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.

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.