Re: [PATCH] Fix race condition when exec'ing setuid files
From: Jorge Merlino
Date: Wed Oct 05 2022 - 12:10:05 EST
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?