4 ms·

this is just a more complex version of the issue where go can't safely do the daemonize dance for a privileged port

• brandon 9y ago
  There's a simple-ish workaround for the privileged port issue if you can't just use CAP_NET_ADMIN: http://play.golang.org/p/dXBizm4xl3 http://play.golang.org/p/dXBizm4xl3 The namespace issues are unfortunately a lot tougher to address.
  • vbernat 9y ago
    It's only reliable if none of your dependencies are spawning goroutines during initialization. If this is the case, some goroutines (yours' or the dependencies') can end up with increased privileges.
    • brandon 9y ago
      The workaround functions by opening the privileged socket and re-executing the binary as an unprivileged user with access to the filehandle. Any background goroutines would exit with the privileged parent. Also: please don't spawn goroutines during init(). There's generally a better time and place, and in the event that you justifiably need a package-level background routine you can spawn it on demand with a sync.Once.
  • the8472 9y ago
    But you also want drop that privilege after using it to get the same effect as the "daemonize dance" GP referred to. And that's also per-thread, just like namespaces.
• cyphar 9y ago
  And that's unfortunately only an issue because Linux doesn't implement POSIX's model for thread privileges. In particular, glibc has to implement the nptl in userspace to make Linux threads look like POSIX threads. I get the feeling that the Go runtime doesn't do the same.