In GNU Coreutils through 8.29, chown-core.c in chown and chgrp does not
prevent replacement of a plain file with a symlink during use of the POSIX
"-R -L" options, which allows local users to modify the ownership of
arbitrary files by leveraging a race condition.
@Maintainers please call for stabilization when ready.
The sentiment from upstream is that this probably can't be fixed, and I sort of agree. So far the only idea that I've had would be to collect and sort all of the paths to be chown'd by *realpath*, and then to process them in depth-first order. Basically, undoing the problem created by the symlink in the PoC (that the traversal becomes not depth-first).
However, there are problems with that approach:
1. For the lawyers, POSIX says that the operation should be performed
recursively. Collecting the paths in one big data structure and
then processing them linearly in a loop is not recursive.
2. How big do we make the aforementioned data structure? A priori, we
don't know how deep the directory trees are.
3. There's a large performance penalty to creating that data structure,
calling realpath on everything, and then sorting the result.
4. You have to rewrite all of the chown/chgrp code for this, and probably
undo ten years worth of bug fixes in the process.
I've posted a documentation patch that basically says "don't do that," but beyond that, am hitting the limits of my imagination.
just in case coreutils-8.30 has the documentation fixes regarding this CVE.
Already in portage tree
We can probably just close this. There's no obvious way to fix the race condition and the upstream fix is just to document that it exists.