Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Oct 2020 12:27:44 +0300
From: Alexey Izbyshev <>
Subject: Calling setxid() in a vfork()-child


I'm investigating possibility of using vfork() instead of fork() in a 
Linux-only application. Before calling execve(), the app might need to 
call some functions to setup the child, including setxid() (let's assume 
that security concerns of [1] are not applicable). I'm aware that POSIX 
doesn't allow that for vfork()-children, but I'm also aware that it 
might be OK on Linux if the set of functions is sufficiently 
constrained, and that vfork() is used to efficiently implement 
posix_spawn() in C libraries. However, setuid()/setgid() seem 
particularly tricky because of the need to call the actual syscall in 
all threads, so if a C library is unaware that setxid() is called in a 
vfork()-child, it might attempt to interact with threads of the parent 
process, potentially causing trouble. I've checked musl and found a 
recent commit[2] that fixes this exact issue. I've also checked 
glibc[3], but haven't found any handling of this case (and vfork() 
doesn't appear to do anything special in this regard either[4]).

Do I understand correctly that, from an application developer 
perspective, it's currently better to avoid setxid/setrlimit libc 
functions in a vfork()-child, and that using syscall() or avoiding 
vfork() entirely is preferred in this case?



Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.