Date: Tue, 13 Oct 2020 04:47:37 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: Calling setxid() in a vfork()-child On Mon, Oct 12, 2020 at 11:30:58PM +0300, Alexey Izbyshev wrote: > Unfortunately, while posix_spawn() + a helper executable would be fine in > many cases (more so for applications than libraries), addition of a helper > to an existing library exposing a process creation API that can't be > implemented in terms of posix_spawn() may be not straightforward. If the > helper is just an executable file, we'll need to locate it, which may be > simply impossible when our library is called if, say, switching mount > namespaces is involved (which may be out of control of our library). > Solutions may exist (locate and open() at startup or memfd_create(), and > then execveat()?), but vfork() (+ preventing execution of signal handlers in > the child) seems so much simpler, and doesn't add the overhead of an extra > execve() too. > > Alexey > If dropping privileges is all you want, then posix_spawn() has a flag for that. And if you are foregoing portability anyway by doing anything between vfork() and execve(), might as well use clone() and do it properly. Yes, locating a helper binary is a bit of a problem. I've been recently struggling with that myself. While you can make the binary part of the main application (or library, in your case), using posix_spawn() means the binary must have a path name, so using tempfile() is out of the question (unless you use the proc file name, which is, again, non-portable). Ciao, Markus
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.