Have you considered using the cap package instead?

Hey Andrew, thanks for the suggestion!
That looks like an awesome library, however after a bit of reading I realized that it modifies capabilities for the whole process. I thought it would also let me change capabilities of a single os thread, but it looks like it's not possible (or I might be missing something).

In my use case I'm doing the following:

go func() { 
  runtime.LockOSThread() // exclusively bind the goroutine to a single os thread.
  unix.Capget/Capset
  unix.Setns // change netns of the os thread
  exec.Start/Wait/Run/etc
  // exit goroutine without unlocking to kill the os thread
} () 

Take a look at the Launch() stuff. There is an example I've been playing with here: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/goapps/gowns/gowns.go

Thanks for the pointer!
Wouldn't work for me though, since I need to raise capabilities first, then do setns. The callback seems to be called before capset (which makes total sense for the use case of dropping capabilities). Also ideally I would like to use a standard exec package to run programs in a net namespace (to handle stdin/stdout the standard way).

Are there any plans to expose cap API with cap.singlesc syscaller underneath? Or alternatively something similar to Launch, but with a callback only. Then I could exec.Start/Wait/etc in the callback instead of relying on ForkExec in the cap package.
Thanks!

You should feel free to make such a feature request. The cap.Launch() and callback mechanism are very much open for development.

[There seems to be a lot of confusion about the importance of POSIX semantics for privilege mechanisms in general though. I wrote this to capture how trivial it is for unprivileged threads to trick the other threads into doing privileged things, for C/C++ but it applies to Go/CGo too.]

Also, I forgot to mention, the Launch() stuff invokes the callback with the prevailing process capabilities, so if your callback needs something raised in pE, you can raise them prior to calling Launch(). I'd be happy to work through any issues you find.

You should feel free to make such a feature request

Thanks! done: https://bugzilla.kernel.org/show_bug.cgi?id=211919

you can raise them prior to calling Launch()

But then I'm back to square one using naked syscalls instead of nice libcap API.