On 13/9/22 19:03, Kees Cook wrote:
I'll want to spend some more time studying this race, but yes, it looks like it should get fixed. I'm curious, though, how did you find this problem? It seems quite unusual to have a high-load heavily threaded process decide to exec.
I just got a response from our customer regarding the situation where this race condition occurs:
Our application is a Rust-based CLI tool that acts as a frontend to cloud-based testing infrastructure. In one mode of operation it uploads a large number of test artifacts to cloud storage, spawns compute instances, and then starts a VPN connection to those instances. The application creates the VPN connection by executing another setuid-root tool as a subprocess. We see that this subprocess sometimes fails to setuid. The "high-load heavily threaded" aspect comes from the fact that we're using the Tokio runtime. Each upload to cloud storage is a separate Tokio task (i.e. "green thread") and these are scheduled onto "N" OS-level threads, where N = nproc. In a large run we may upload a couple thousand artifacts but limit to 50 concurrent uploads. Once these artifact uploads complete, we typically spawn the setuid subprocess within 1-2 seconds.
Have you been able to look at this issue? Thanks Jorge
