Linux, unix.Capset, and runtime.LockOSThread

[Caleb Spare]

Hi! I have a Linux-specific question about capabilities, threads, and syscalls.

I have a Go program which runs other programs with specific
capabilities set. It basically does the following:

cmd := exec.Command(...)
runtime.LockOSThread()
unix.RawSyscall(unix.CAPSET, ...)
cmd.Start()

Empirically, it seems to work well, having run in production for several years.

I wrote it this way because, from my reading of capabilities
documentation, capset only affects the current thread, so it's
important that we use the same OS thread for running the capset
syscall as the fork. I also used RawSyscall (rather than Syscall) for
this reason.

I noticed that more recently the x/sys/unix package added Capget and
Capset which use Syscall rather than RawSyscall. Thinking about it
more now, ISTM that using Syscall is fine, and that LockOSThread is
all I need to ensure that the thread with the raised capabilities is
the one that runs the fork. Is that correct?

Relatedly, how does one definitively know whether a syscall is
nonblocking? AFAICT setcap and getcap shouldn't block. Why does unix
use Syscall for Capset/Capget but RawSyscall for calls like Getpgid?

Thanks!
Caleb

[Ian Lance Taylor]

On Thu, Feb 13, 2020 at 1:14 PM Caleb Spare <ces...@gmail.com> wrote:
>
> Hi! I have a Linux-specific question about capabilities, threads, and syscalls.
>
> I have a Go program which runs other programs with specific
> capabilities set. It basically does the following:
>
> cmd := exec.Command(...)
> runtime.LockOSThread()
> unix.RawSyscall(unix.CAPSET, ...)
> cmd.Start()
>
> Empirically, it seems to work well, having run in production for several years.
>
> I wrote it this way because, from my reading of capabilities
> documentation, capset only affects the current thread, so it's
> important that we use the same OS thread for running the capset
> syscall as the fork. I also used RawSyscall (rather than Syscall) for
> this reason.
>
> I noticed that more recently the x/sys/unix package added Capget and
> Capset which use Syscall rather than RawSyscall. Thinking about it
> more now, ISTM that using Syscall is fine, and that LockOSThread is
> all I need to ensure that the thread with the raised capabilities is
> the one that runs the fork. Is that correct?

Yes.

The difference between Syscall and RawSyscall is that the latter does
not inform the scheduler that it is entering the kernel, and therefore
using RawSyscall will break your program if the system call blocks.
There is no difference between Syscall and RawSyscall with regard to
the behavior of LockOSThread.

> Relatedly, how does one definitively know whether a syscall is
> nonblocking? AFAICT setcap and getcap shouldn't block. Why does unix
> use Syscall for Capset/Capget but RawSyscall for calls like Getpgid?

It's possible that this is a performance bug. I don't know of any
reason why Capset/Capget might block.

Ian

[Caleb Spare]

Thanks for the reply.

Okay, I can send a CL for that.

>
> Ian