On 09/16/2015 11:37 AM, Ian Lance Taylor wrote:
> I think the resistance is straightforward. The syscall package is
> frozen. We only change it when we must. We must change it for
> operations that are required to occur between fork and exec. This
> operation is not required to occur between fork and exec. Therefore
> we should not implement it. (If we have made earlier changes that
> were not required to occur between fork and exec, then we received
> incorrect information and made a mistake.)
> The question here is: is providing a way to call setns between fork
> and exec so convenient that we should break the rules that we have
> already set?
Let me start out by saying that as a default stance, I highly favor the stability vote.
However, in this case? It really may be still worth considering.
Reading the current stdlib code around fork/exec races, I can palpably feel the head-in-hands frustration of the author. Imagine the same frustration someone would have trying to get filedescriptor closure right for a security project without that. Namespaces are now very much stuck there.
If it is somehow possible to write the desired namespaced process launch features as a library, sans self-execing or cgo, the "no, it's frozen" answer is much bolstered, since the answer to "freeze" situations is typically "make a library". While that's clearly fine for, say, better/different json... reading the current race comments in fork/exec code, it's not clear to me this is possible to do as a library, and others on this list suggesting callbacks from the sticky spot seem to be saying the same, so we have a rock and a hard place for sure. I hear the concern that blithely adding a callback now will stick us with supporting it in the future; following that thought a little further, are there ideas for (possibly far-)future changes that would indeed deprecate such a hack?
(Trying to do this in cgo or self-execing reminds me of darker days when the letters were JNI instead of CGO, and as a personal anecdote, the joy of a language that decided to be better at speaking OS primitives *without* c wrappers is part of why golang has become dear to me.)