Here's an alternative title for this post: these days, two lines in a systemd service file can easily constrain arbitrary applications to just the files and resources they need, and only those.
You can always use a simpler init system if you want
tl;dr: systemd isn't meant to be an init system, it's meant to manage services, and the alternative world where you don't have a unified system for managing services and events actually sucks.
And worst: want to understand what the actual security properties of your policy are? The answer is buried very, very deep.
Systemd didn’t “break” anything at all here. This author’s arcane debugging workflow doesn’t work for certain units who have opted into the new security mechanisms. But that is hardly systemd’s fault.
You do realize distros can also change SysV shell scripts in ways that break your use case as well, right?
Like imagine a list where we can create a form where people can give them and give reasonings or just something.
What if I can create a github repo and issues regarding this so that we can discuss about them and I can create a website later if it interests but its a really nice thought experiment.
Are we talking more about uh every software including proprietory too?
Are we talking about lets say websites too or services (what if we extend it to services like websites or even products outside of software niche into things beyond too, that's interesting too)
Another interesting point that comes to my mind might be that cryptocoins might be the lowest inverse to this software project in the sense that I believe that there was very little net positive done to all humanity in general, sure the privacy aspects are nice but still, its not worth having people invest their life savings into it thinking that its going to 100x y'know, I have created a whole article about it being frustated by this idea people think regarding crypto as an investment when it could very well be a crypto"currency" but that's a yap for another day.
I really nerded over this and I think I loved it, we need a really good discussion about it :>
Systemd is strictly better than what came before it, while Wayland still has missing functionality and breaks a lot of use cases.
This can help troubleshoot issues and makes experimenting with systemd options faster.
I think there's been some talk about adding a built-in way for systemd-run to copy settings out of a .service file, but it doesn't exist yet.
I've written Perl/Python scripts to do this for me. They're not really aimed at working with arbitrary services, but it should be possible to adapt to different scenarios.
https://gist.github.com/dextercd/59a7e5e25b125d3506c78caa3dd...
There are some gotchas I ran into. For example, with RuntimeDirectory: systemd deletes the directory once the process exits, even if there's still another process running with the same RuntimeDirectory value set.
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?
zdw•1h ago
Seeing that podman can run containers as systemd services (see https://codesmash.dev/why-i-ditched-docker-for-podman-and-yo... ), it seems like using containers other than as a distribution mechanism has few advantages, and many disadvantages in terms of dependency updates requiring container rebuilds.
baby_souffle•1h ago
I see it as _exactly_ the opposite. Podman gives me more or less the same security controls as systemd and the package/delivery problem is solved.
Call me when `systemctl pull ...` fetches the binary and everything else needed to run it _and_ puts the .service file in the right spot.
JoBrad•56m ago
That would be pretty awesome, actually.
o11c•43m ago
That seems like a `machinectl` task though.
speed_spread•43m ago
zdw•14m ago
Back in the old days (late 90's, early 2k's) as a sysadmin I'd often write scripts to chroot or in other ways isolate services rather than run them as root, so extending the init system to handle those features feels like it's a logical extension, not a incompatible replacement.
jeroenhd•6m ago
9dev•56m ago
nickysielicki•44m ago
https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
arianvanp•38m ago
importctl pull-tar https://example.com/image.tar.gz && portablectl attach image
vlovich123•34m ago
ndriscoll•30m ago
miladyincontrol•50m ago
I dont get the distribution "advantage" building em with mkosi but I'd argue it a weakness as far too many are running containers with who-knows-what inside them.
oncallthrow•41m ago
Do you work in the software industry?