lighttpd problem with systemd configuration file
Hi All, Around late spring the cgi-bin components of web pages I wrote started failing under lighttpd with what looked like permission problems. After much debugging I tracked the problem down to a configuration file lighttpd installs for systemd, namely /lib/systemd/system/lighttpd.service which is symlinked by /etc/systemd/system/multi-user.target.wants/lighttpd.service. The lighttpd developers added a configuration parameter (ProtectHome=read-only) that completely disables cgi-bin access. My problem is that the file is not treated by lighttpd as a configuration file, the next install of lighttpd ( I use Debian) rewrites the file. This behavior seems puzzling to me as lighttpd went to a lot of trouble to support cgi-bin and the debian package is disabling it every update. Does anyone know of a work-around? -- Michael Galea
Michael Galea via Talk wrote on 2025-08-26 11:36:
The lighttpd developers added a configuration parameter (ProtectHome=read-only) that completely disables cgi-bin access.
For anyone interested, from `man systemd.exec` (hard to find that, I tried `man systemd.unit then `man systemd.service`, then had to search for it. Bad discoverability.): ProtectHome= Takes a boolean argument or the special values "read-only" or "tmpfs". If true, the directories /home/, /root, and /run/user are made inaccessible and empty for processes invoked by this unit. If set to "read-only", the three directories are made read-only instead. If set to "tmpfs", temporary file systems are mounted on the three directories in read-only mode.
My problem is that the file is not treated by lighttpd as a configuration file, the next install of lighttpd ( I use Debian) rewrites the file. This behavior seems puzzling to me as lighttpd went to a lot of trouble to support cgi-bin and the debian package is disabling it every update.
Sounds like a well-intentioned mis-config by Debian (not lighthttpd), as that man page says: It is recommended to enable this setting for all long-running services (in particular network-facing ones), to ensure they cannot get access to private user data, unless the services actually require access to the user's private data.
Does anyone know of a work-around? From `man systemctl` and searching " edit", one can create "drop-in" files that contain snippets of directives for systemd on a per-service level.
So, systemctl edit lighthttpd should open $your_editor with the current settings commented out but there for guidance. i.e.: systemctl edit postgresql@14-main.service ### Editing /etc/systemd/system/postgresql@14-main.service.d/override.conf ### Anything between here and the comment below will become the contents of the drop-in file [Unit] ... ## here are the contents of any user changes already made ... [Service] ... ### Edits below this comment will be discarded ... ## here are the contents of the .service file, commented out Change ProtectHome= to No in the advised location. Saving the edit will create a file like (see first line of text file in editor for exact location): ### Editing /etc/systemd/system/postgresql@14-main.service.d/override.conf Alternately, `systemctl set-property lighthttpd.service ProtectHome=No` should create some file like: ### Editing /etc/systemd/system/postgresql@14-main.service.d/ProtectHome.conf Hopefully this will help resolve the problem! Keep me / us posted if it does or does not work, and any tweaks needed. Thanks
Ron via Talk wrote on 2025-08-26 14:23:
After much debugging I tracked the problem down to a configuration file lighttpd installs for systemd, namely /lib/systemd/system/ lighttpd.service which is symlinked by /etc/systemd/system/multi- user.target.wants/lighttpd.service.
The lighttpd developers added a configuration parameter (ProtectHome=read-only) that completely disables cgi-bin access.
I forgot to say, that's some good detective work.
### Editing /etc/systemd/system/postgresql@14-main.service.d/ ProtectHome.conf
And on this topic, I forgot to say that files in /etc/systemd are meant to override the default files in /lib/systemd. So replacing the symlink in /etc/systemd with a copy of the orig file and making changes there is another option that will persist between re-installs. (Unless un-installed with --purge, maybe?) But the overrides / drop-ins are a nifty way to make changes to defaults that can be easily moved between machines, etc.
On 2025-08-26 17:40, Ron via Talk wrote:
Ron via Talk wrote on 2025-08-26 14:23:
After much debugging I tracked the problem down to a configuration file lighttpd installs for systemd, namely /lib/systemd/system/ lighttpd.service which is symlinked by /etc/systemd/system/multi- user.target.wants/lighttpd.service.
The lighttpd developers added a configuration parameter (ProtectHome=read-only) that completely disables cgi-bin access.
I forgot to say, that's some good detective work.
### Editing /etc/systemd/system/postgresql@14-main.service.d/ ProtectHome.conf
And on this topic, I forgot to say that files in /etc/systemd are meant to override the default files in /lib/systemd.
So replacing the symlink in /etc/systemd with a copy of the orig file and making changes there is another option that will persist between re- installs.
(Unless un-installed with --purge, maybe?)
But the overrides / drop-ins are a nifty way to make changes to defaults that can be easily moved between machines, etc. ------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/ talk@lists.gtalug.org/message/GVUREPGIJUSTDN7FBAYL6BCEQR6OMTBO/
Thanks Ron, I tried to follow your original instructions. I think that, because I fixed the problem in the spring by editing a file systemd file directly, the systemd edit process failed on me, going very strange. But after trying to repair systemd for a while I just directly created a /etc/systemd/system/lighttpd.service.d directory containing an override.conf which set ProtectHome=no. That worked fine. PS: systemd is really sticky. Uninstalling and reinstalling lighttpd was not enough to reset its state on lighttpd. Google suggested I do a complete purge of the lighttpd package, including configuration to get systemd cleaned up. -- Michael Galea
Michael Galea via Talk wrote on 2025-08-26 16:11:
I tried to follow your original instructions. I think that, because I fixed the problem in the spring by editing a file systemd file directly, the systemd edit process failed on me, going very strange.
Huh, I'm now curious on what went wrong.
But after trying to repair systemd for a while I just directly created a /etc/systemd/system/lighttpd.service.d directory containing an override.conf which set ProtectHome=no. That worked fine.
Well, since it's working, that's great. Same result as `systemctl edit lighttpd` but manual.
PS: systemd is really sticky. Uninstalling and reinstalling lighttpd was not enough to reset its state on lighttpd.
I did a few searches on the topic and didn't find much, but Debian is providing the packaging and so they created the systemd unit file as best I can tell. Seems like they haven't really documented that, for CGI scripts hosted outside /var/www/cgi-bin one needs to make the ProtectHome=no change. I have no idea how common it is these days for www.domain.tld/~user/cgi-bin/script.pl or whatever. Don't think I've seen such an URL for a long time, so I assume it's rare now. Except for putty, and they paid the price for it by having someone else register putty[dot]org and post anti-vax nonsense there. Oops. Putty, the only ~/user URL still in existence: https://www.chiark.greenend.org.uk/~sgtatham/putty/ They had to register https://putty.software just this month because they stayed on the URL above for way too long. But, lots of people who use CGI also use lighttpd, so it probably should be clearly mentioned in the documents. Thanks for the update.
On 2025-08-28 06:45, Ron via Talk wrote:
Michael Galea via Talk wrote on 2025-08-26 16:11:
I tried to follow your original instructions. I think that, because I fixed the problem in the spring by editing a file systemd file directly, the systemd edit process failed on me, going very strange.
Huh, I'm now curious on what went wrong.
But after trying to repair systemd for a while I just directly created a /etc/systemd/system/lighttpd.service.d directory containing an override.conf which set ProtectHome=no. That worked fine.
Well, since it's working, that's great.
Same result as `systemctl edit lighttpd` but manual.
PS: systemd is really sticky. Uninstalling and reinstalling lighttpd was not enough to reset its state on lighttpd.
I did a few searches on the topic and didn't find much, but Debian is providing the packaging and so they created the systemd unit file as best I can tell.
Seems like they haven't really documented that, for CGI scripts hosted outside /var/www/cgi-bin one needs to make the ProtectHome=no change.
I have no idea how common it is these days for www.domain.tld/~user/cgi- bin/script.pl or whatever. Don't think I've seen such an URL for a long time, so I assume it's rare now.
Except for putty, and they paid the price for it by having someone else register putty[dot]org and post anti-vax nonsense there. Oops.
Putty, the only ~/user URL still in existence:
https://www.chiark.greenend.org.uk/~sgtatham/putty/
They had to register https://putty.software just this month because they stayed on the URL above for way too long.
But, lots of people who use CGI also use lighttpd, so it probably should be clearly mentioned in the documents.
Thanks for the update.
------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/ talk@lists.gtalug.org/message/SDSLRFOOZ7TYX3YQLKKN457GCAQZOISN/
Hi Ron, Fist of all, I know I created the problem in the first place by editing a systemd component that contained configuration data. The proper way to solve the problem, with systemd edit kept configuration changes in /etc, where I back it up. I'm happy with that. I went back to the console that I used to run the command and found: mg:/etc/systemd# systemctl edit lighttpd.service Found modifications outside of the staging area, which would be discarded. /etc/systemd/system/lighttpd.service.d/override.conf: after editing, new contents are empty, not writing file. So the problem was systemd detecting and complaining about my changes to /lib/systemd/system/lighttpd.service. i have since practiced systemd edit on both some projects I have written that used systemd and on the working lighttpd service file. Both edits now work fine. -- Michael Galea
Ron via Talk wrote on 2025-08-26 14:23:
from `man systemd.exec` (hard to find that, I tried `man systemd.unit then `man systemd.service`, then had to search for it. Bad discoverability.): So, that's at least half my fault:
The -K or --global-apropos option is what I should have used, not "-k": man -K ProtectHome $ man -K ProtectHome --Man-- next: systemd.exec(5) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ] --Man-- next: org.freedesktop.systemd1(5) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ] --Man-- next: systemd.directives(7) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]
Michael Galea via Talk said on Tue, 26 Aug 2025 14:36:27 -0400
Hi All, Around late spring the cgi-bin components of web pages I wrote started failing under lighttpd with what looked like permission problems.
After much debugging I tracked the problem down to a configuration file lighttpd installs for systemd, namely /lib/systemd/system/lighttpd.service which is symlinked by /etc/systemd/system/multi-user.target.wants/lighttpd.service.
Does anyone know of a work-around?
LOL, who's buried in Grant's Tomb? Dump * system * D Switch from Debian to Devuan, and all the systemd overcomplexifications will be history for you. SteveT Steve Litt http://444domains.com
Steve Litt via Talk wrote on 2025-08-26 19:21:
Does anyone know of a work-around?
LOL
Anything starting with that is almost guaranteed to be dumb. Let's see...
Dump * system * D
Switch from Debian to Devuan,
Yep, the record remains unbroken.
and all the systemd overcomplexifications will be history for you.
I never hear complaints about the complexity of bash, nor postfix (over 1000 options!), nor X11 - which even Xorg thinks is no longer maintainable and is also insecure. Never a word about those. Apparently "hypercomplexifications" pertaining to systemd means "I'm old, I refuse to learn anything new for at least the last decade". First you complain that systemd is too complex and therefore a security problem. Then we see a clear example where a simple directive like "ProtectHome" can be used to harden any server on the system with a single line of readable text and now you advocate for ... discarding the security advantages and going back to old tech. Which can't provide this protection. If anyone wants some background, here's a turdnugget from Steve's GOLUG just last week with Steve, me, and Steve quoted:
there was absolutely nothing wrong with sysvinit's PID1 in the 00's
And yet multiple teams of Linux experts at Canonical, RedHat, etc. were looking to replace it.
Who are we to think has greater knowledge on the topic?
Me. Seriously. The inability to distinguish between PID1 and the service manager/supervisor shows them to be either idiots, or for- profit Linux companies wanting to profit from the hypercomplexification of Linux.
So: * only I know the truth * the experts are idiots * there's a huge conspiracy Make of that what you will, seems kinda Qanon-adjacent levels of hubris and muddled thinking to me.
Ron via Talk said on Wed, 27 Aug 2025 01:30:03 -0700
Steve Litt via Talk wrote on 2025-08-26 19:21:
Does anyone know of a work-around?
LOL
Anything starting with that is almost guaranteed to be dumb.
Let's see...
Dump * system * D
Switch from Debian to Devuan,
Yep, the record remains unbroken.
Como se dice "Yep, the record remains unbroken" en Englais? Wie sagt man "Yep, the record remains unbroken" in English? In other words, "huh?"
and all the systemd overcomplexifications will be history for you.
I never hear complaints about the complexity of bash,
Bash does one thing and does it well: It serves as a great *interactive* shell. It doesn't have tentacles into the entire software system. As far as a shell scripting language, why would anybody use bash when ksh and dash are available?
nor postfix
Once again, postfix doesn't influence anything except for email, whereas systemd influences over 50% of the computer's software systems. To answer your question about why I don't complain about the complexity of postfix, it's because I don't use it. If I needed a full SMPT server, I'd use one of the others as a substitute, just like I use runit as a substitute for systemd and sysvinit.
(over 1000 options!), nor X11 - which even Xorg thinks is no longer maintainable and is also insecure.
X11 is a hypercomplexificated junkpile, and I look forward to the day when we have a *real* improvement on it. I don't think Wayland fits the bill, at least not yet. In the same way, sysvinit had/has real problems, but systemd is not a solution. Systemd is more like falling out of the pan and into the fire.
Never a word about those.
Apparently "hypercomplexifications" pertaining to systemd means "I'm old, I refuse to learn anything new for at least the last decade".
I learned Rust. I'm in the process of learning Go. I just added the superior (and fairly new) uv Python package manager to some of my Python programs. Hypercomplexifications doesn't mean unwillingness to learn, it means just what it says: https://www.troubleshooters.com/linux/systemd/lol_systemd.htm
First you complain that systemd is too complex and therefore a security problem.
True, but I care more about the difficulty of troubleshooting tightly welded systems, and the lack of DIYability such systems bring.
Then we see a clear example where a simple directive like "ProtectHome" can be used to harden any server on the system with a single line of readable text and now you advocate for ... discarding the security advantages and going back to old tech.
Which can't provide this protection.
I spent 10 minutes researching "ProtectHome". It's an excellent idea. A per-daemon barrier to /home, /root, and /run/user. My research showed it seems to cause problems for a lot of people. It's a great idea. I suspect it could be made more general (why just those three directories, and why those three as a package deal) and can also be done using a separate software component with a thin linkage to runit's runsv command. If I needed this, I'd do it myself.
If anyone wants some background, here's a turdnugget from Steve's GOLUG just last week with Steve, me, and Steve quoted:
there was absolutely nothing wrong with sysvinit's PID1 in the 00's
And yet multiple teams of Linux experts at Canonical, RedHat, etc. were looking to replace it.
OK, perhaps I misspoke. What I meant is there's nothing wrong with sysvinit's pre-daemon-handling code. Sysvinit's problem was its process handling. Canonical, RedHat etc could have easily plugged in Daemontools, which existed since 2001, to get rid of those awful init scripts *and* do parallel instantiation. But that's not their style: Daemontools was just sooooo NIH (Not Invented Here). They could have just added the following line to /etc/inittab: SV:12345:respawn:/command/svscanboot No need for Upstart or systemd. But noooooo! I was using daemontools for some of my processes since about 2006, and it worked great. SteveT Steve Litt http://444domains.com
participants (4)
-
Anthony de Boer -
Michael Galea -
Ron -
Steve Litt