[Turris v1.1] - Lighhtpd auth module mod_authn_file.so

Software SW bugs discussion
1

Hi,
I have old Turris v1.1.
After yesterdays major update, I tried to login to web administration, but I reached only basic authentication popup. Since I was using basic auth as part of my lighttpd setup I trustfully entered several combinations of users / password combinations I am using on router and since none of them worked I started to investigate whats going on.
I realized soon, that my lighttpd server has problem with starting, throwing exception:
root@Turris:~# /etc/init.d/lighttpd restart 2016-12-09 07:44:20: (configfile-glue.c.47) DEPRECATED: don't set server options in conditionals, variable: server.errorlog 2016-12-09 07:44:20: (configfile-glue.c.47) DEPRECATED: don't set server options in conditionals, variable: server.errorlog 2016-12-09 07:44:20: (configfile-glue.c.47) DEPRECATED: don't set server options in conditionals, variable: server.errorlog Syntax OK /usr/lib/lighttpd/mod_alias.so /usr/lib/lighttpd/mod_cgi.so 2016-12-09 07:44:20: (configfile-glue.c.47) DEPRECATED: don't set server options in conditionals, variable: server.errorlog 2016-12-09 07:44:20: (configfile-glue.c.47) DEPRECATED: don't set server options in conditionals, variable: server.errorlog 2016-12-09 07:44:20: (configfile-glue.c.47) DEPRECATED: don't set server options in conditionals, variable: server.errorlog 2016-12-09 07:44:20: (plugin.c.227) dlopen() failed for: /usr/lib/lighttpd/mod_authn_file.so File not found 2016-12-09 07:44:20: (server.c.912) loading plugins finally failed

And since nor http nor https server was up on router, I assume that I entered all my combinations into brand new http minipot… :frowning: Could you please confirm if this was what probably happened and if this means, that passwords I have entered has been already sent out and I have to stop using them now? Could you please share more technical details including used service for collecting password to it could be stopped / disabled? I made an attempt to find what is running on port 80 using netstat command but I was obviously unsuccessful assuming you want to avoid of conflict listening on same port.

Since I was using basic auth on my lighttpd setup before, I quickly found where the problem was:
in /etc/lighttpd/modules.d directory there was a 20-auth.load file which includes server.modules += ( "mod_auth" ) directive and I had to disable this resulting in lighttpd to run fine, but my obviously this leasves my internal pages I want to have secured unprotected now!
PS It seems to be bug described here: https://github.com/openwrt/packages/issues/3502

2

It’s really the source of the bug. The bug itself is somewhere in Turris infrastructure. As you can see here, the OpenWRT distribution now includes one more module called mod_authn_file. But Turris’ OpenWRT doesn’t include it for now(see here).

3

Yep, same problem here. Unfortunately seems that mod_auth and mod_authn are different one and not possible to get those easily…
Some idea for workaround?

4

Taken from Twitter:
“Hello. We’re working on this matter. It should be fixed during January.”

5

After update to Turris v3.5 I had to ssh into CLI and remove auth package using following command, since when package is installed, lighttpd is refusing to start again.
opkg remove lighttpd-mod-auth
I have probably installed that package, when I was debugging the problem in the middle of December.
JR

6

Unfortunately this error is still alive, so we cannot use basic HTTP auth in embedded lighttpd web server. Turris team, please update your lighttpd-mod-auth package with new version from openwrt upstream. Package should includes mod_authn_file.so file which causing our errors.