> One of the traditional rites of passage for Linux system administrators is having a daemon not work in the normal system configuration (eg, when you boot the system) but work when you manually run it as root.
I've don't remember the last time I run a daemon by hand (that I wasn't developed it myself). I always just run the systemd unit via systemctl and debug that.
> A standard thing I do when troubleshooting a chain of programs executing programs executing programs is to shim in diagnostics that dump information to /tmp.
This seems like a very esoteric case in the days of structured logging and log levels.
> A mailer usually can't really tell the difference between 'no one has .forward files' and 'I'm mysteriously not able to see people's home directories to find .forward files in them'
Obviously a daemon that should access files in people's home directories shouldn't have ProtectHome=true. It's the responsibility of the daemon developer or the package maintainer to set appropriate flags based on what the daemon does. Someone had to explicitly write "ProtectHome=true". It's not the default, and it doesn't just appear in the service file.
When in doubt don't set security options at all, instead of shipping a broken daemon that you don't understand why it doesn't work.
Note: please base your daemon on D-Bus or a socket in /run and not on reading arbitrary files from my home directory.
I also don't understand the larger perspective? Should we not make our daemon run in more secure environments?
Are those days in the same room we are? Because last I have checked, logging is generally implemented as a stream of text messages with a very few bits of structured metadata. Like, almost in every piece of software in existence.
> log levels.
Those exist for decades and were invented long before anything that could be considered "structured logging".
> Should we not make our daemon run in more secure environments?
I want systemd to get out of my lawn and stop adding features. It's not the job of /sbin/init to setup specifics of the secure environment. I want my init to launch daemons and that's it.
I've don't remember the last time I run a daemon by hand (that I wasn't developed it myself). I always just run the systemd unit via systemctl and debug that.
> A standard thing I do when troubleshooting a chain of programs executing programs executing programs is to shim in diagnostics that dump information to /tmp.
This seems like a very esoteric case in the days of structured logging and log levels.
> A mailer usually can't really tell the difference between 'no one has .forward files' and 'I'm mysteriously not able to see people's home directories to find .forward files in them'
Obviously a daemon that should access files in people's home directories shouldn't have ProtectHome=true. It's the responsibility of the daemon developer or the package maintainer to set appropriate flags based on what the daemon does. Someone had to explicitly write "ProtectHome=true". It's not the default, and it doesn't just appear in the service file.
When in doubt don't set security options at all, instead of shipping a broken daemon that you don't understand why it doesn't work.
Note: please base your daemon on D-Bus or a socket in /run and not on reading arbitrary files from my home directory.
I also don't understand the larger perspective? Should we not make our daemon run in more secure environments?