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.
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.

So am I missing any reason why an os.StartProcess-like API for exec-ing
would be untenable?

Thanks!
Caleb

-- 
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.

Reply via email to