CVE-2017-18018 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-18018): 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. Thank you
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.
(In reply to Michael Orlitzky from comment #3) > 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. Works for me. A documentation warning does not warrant a GLSA imho, closing.
