1. 23
  1.  

  2. 16

    I’d be more inclined to blame linux here. Letting different threads run in different namespaces is insane. (Linux also makes setuid() per thread. That, too, is insane.)

    There’s a worse is better philosophy, here, that threads are just processes sharing a VM space, but I think the minimalism is taken too far. There are other properties, like uid, that people expect to be shared between processes as well.

    1. 6

      Linux also makes setuid() per thread. That, too, is insane.)

      Oh. Oh dear.

      EDIT:

      NPTL (native posix threads for linux) is the workaround:

      At the kernel level, user IDs and group IDs are a per-thread attribute. However, POSIX requires that all threads in a process share the same credentials.

      The NPTL threading implementation handles the POSIX requirements by providing wrapper functions for the various system calls that change process UIDs and GIDs. These wrapper functions (including the one for setuid()) employ a signal-based technique to ensure that when one thread changes credentials,all of the other threads in the process also change their credentials.

      For details, see nptl(7).

      1. 1

        I’ve always wondered what the word native means in that context, because really, it’s a userspace emulation of posix threads on top of linux clones.

        1. 1

          Oh, so the Go issue of not being able to change user reliably do not really apply to go programs on openbsd?

          1. 2

            Nope. A process can only have one user id, shared by all threads.

      2. 5

        Once you generalize the thread title to “thread global state and Go don’t mix” it slides into place and seems a little less ridiculous.

        For 99% of use cases you want your entire process to be in one namespace anyways, which is probably handled by your orchestration framework using something like https://github.com/google/nsjail

        1. 3

          Once you generalize the thread title to “thread global state and Go don’t mix” it slides into place and seems a little less ridiculous.

          An interesting effect is that even if you can explain people these general concepts quite fine, they will fail to apply them in specific situations - maybe by missing that it even applies here (by namespaces having thread-local behavior).

          I still agree with the posts conclusion that using Go goroutines for command line apps driving Linux internals exposes you to all these behaviours very easily.

        2. 1

          Oh, oops, for clarity, last sentence should read shared between threads as well.