CVE-2017-18188: Unsafe use of recursive chown in "Z" support #3
The tmpfiles.d specification for the
The first time that opentmpfiles-setup is launched, everything is fine. But then my "mjo" user owns the directory in question, and I can create a hard link...
and restart opentmpfiles-setup...
and now I own
This happens, ultimately, because
I would say the problem is in the tmpfiles.d specification. Ultimately, there's no reason why you should ever have to "fix" permissions at startup: temporary directories will be gone, so you can create them anew with the correct permissions (mkdir/chown the top-level directory, and then drop privileges to create the rest); and non-temporary directories should still be there from before.
But, the tmpfiles.d specification allows it, so people do it. And it turns out to be impossible to adjust permissions on user-controlled files in a safe manner using only POSIX features. Systemd uses a Linux-specific trick to do it safely. The way