On 2023-09-17 08:26:50, Alexe Stefan wrote: > One is written in shell, the other is written in c.(no problems here) > One is not part of systemd, the other is. > How are they identical.
The big picture is that the tmpfiles.d specification is impossible to implement securely on a POSIX system. The systemd devs wrote a specification to appease the people who complained, but that doesn't change the fact that the spec is fundamentally flawed unless you happen to be implementing it on a new linux system. (The authors didn't know this at the time, so it was not a dirty trick.) As a result, opentmpfiles never should have tried to implement it, but its authors didn't know about those problems either. And while implementing tmpfiles in C has certain unavoidable race conditions, hooooooooo boy is the shell version swiss cheese. There's no safe way to run chown and chmod (the shell commands) as root in a directory you don't control, and that's a big part of what opentmpfiles does. The exploits for the shell version are kindergaren stuff. The systemd folks put in a lot of work to make sure that the race window is a small as possible in systemd-tmpfiles. And on linux with kernel hardening, you're safe. Given that no one is working towards replacing tmpfiles completely, here's where that leaves us. We have the systemd utility that is as secure as possible, and opentmpfiles that tries to mimic it but is unmaintained and much less secure. At best, the insecure version could be rewritten in C to make it.... basically identical to the systemd version? Which has no real problems aside from the fact that it has systemd in the name. And no one is volunteering to do that rewrite in the first place. Newer linux systems are well supported by systemd-tmpfiles, and that's the only place tmpfiles is safe to begin with. It sucks that we're all stuck with tmpfiles now but you're only shooting yourself in the foot if you insist on using the worst possible implementation of it.
