Re: [PATCH] Fix race condition when exec'ing setuid files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux