Messages in this thread | | | Date | Wed, 5 Oct 2022 13:09:36 -0300 | Subject | Re: [PATCH] Fix race condition when exec'ing setuid files | From | Jorge Merlino <> |
| |
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
| |