This just cements my conviction that file systems not having transactional operations is a huge omission nowadays. It really is time to start having file systems that are not just huge mutable spaces, and be more like proper ACID databases.<p>I hope somebody is working on it because as things are going in the last years, I'd be retired before I have the time for it.
<p><pre><code> (cd "$path" && [ "$(pwd -P)" = "$path" ] && chown -R buildkite-agent:buildkite-agent .)
</code></pre>
the real question though is why they're trusting just Docker alone to isolate customers; if they want the jobs to effectively be a single user to the system, they can even use unprivileged user namespaces?
I have a small project in this approximate area:<p><a href="https://www.kylheku.com/cgit/safepath/about/" rel="nofollow noreferrer">https://www.kylheku.com/cgit/safepath/about/</a><p>safepath is a function which tries to analyze whether a path is safe to use. Roughly that means that it doesn't resolve in some way that can be controlled by another (non-root) user.<p>A something similar to this is in TXR Lisp under the name path-components-safe:<p><a href="https://www.kylheku.com/cgit/txr/tree/stdlib/path-test.tl?hl=txr-291#n206" rel="nofollow noreferrer">https://www.kylheku.com/cgit/txr/tree/stdlib/path-test.tl?hl...</a>
There would traditionally been another TOCTOU is the described solution, namely hardlinks. This can often be used to get root to do something to a file it shouldn't.<p>The trad solution is to have user writeable areas (home, vartmp, tmp) on different volumes. Some tools have options to not traverse symlinks across volumes for this and other reasons. But on modern systems you are protected by the fs.protected_hardlinks setting.<p><a href="https://wiki.alpinelinux.org/wiki/Sysctl.conf" rel="nofollow noreferrer">https://wiki.alpinelinux.org/wiki/Sysctl.conf</a>