On Tue, Aug 21, 2018 at 3:06 PM Manlio Perillo <manlio.peri...@gmail.com> wrote:
> On Tuesday, August 21, 2018 at 9:50:23 AM UTC+2, Caleb Spare wrote: >> >> I was recently trying to write a Go program that's something like chpst >> or setpriv: it execs another program with an altered process state by >> changing the user ID or modifying the ambient capabilities. (My program is >> Linux-specific.) >> >> In Go, when you want to spawn another process (fork+exec in Posix-land) >> you have the option of a very high-level API in os/exec or a lower-level >> API in the form of os.StartProcess. But os.StartProcess still does a lot of >> work. In my program where I need to exec without forking, I did not have >> the benefit of either os/exec or os.StartProcess, and I ended up having to >> copy Linux-specific code from the syscall package here: >> >> >> https://github.com/golang/go/blob/187a41dbf730117bd52f871009466a9679d6b718/src/syscall/exec_linux.go#L104 >> >> If I wanted to fork+exec, then I could've implemented my features easily >> by using the fields in the platform-specific syscall.SysProcAttr. However, >> because I wanted to exec only, no easy options were available to me, and my >> code ended up doing about a dozen raw syscalls, using runtime.LockOSThread, >> using unsafe, and being generally unpleasant. >> >> My question is: would it make sense to add an API similar to >> os.StartProcess for exec-without-fork? For now I'm just wondering if there >> is any showstopper that makes this unreasonable; if there isn't then I'll >> file a proposal with more details. >> >> Here are two potential problems that I considered: >> >> 1. Is exec-without-fork fundamentally at odds with Go and its runtime >> somehow, like fork-without-exec is? I don't see why that would be the case. >> > > fork without exec simply does not work with multithreading programs: > https://thorstenball.com/blog/2014/10/13/why-threads-cant-fork/ > I understand that. I was asking if there's a similar problem for exec-without-fork, and it sounds like there's not. > > Also, fork is not supported on Windows (well, AFAIK it can be implemented > but it is an hack). > > 2. Is the concept of exec-without-fork incoherent on non-Posix systems? I >> mainly worry about Windows; after some brief googling it did seem like you >> can exec on Windows, though I admit the situation isn't at all clear to me. >> >> > exec is not supported on Windows. > Yeah, Windows and other less-posix-y platforms seem to be the main problem here. > > > >> So am I missing any reason why an os.StartProcess-like API for exec-ing >> would be untenable? >> >> Thanks! >> Caleb >> > > > Manlio > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
