It probably matters for Go since presumably the go runtime starts up some of it’s worker threads before calling your main. Though actually now I’m not so sure, seems worth digging into.
It has mostly died down but a segment of the developer community took great exception to the designers of Go calling it a "systems" language when it had GC, which, as everybody knows, makes it worthless for all tasks ever. (Sarcasm.) However, in my experience, the bigger problem with it as a "systems language" is that the runtime has already spawned off threads by the time the first line of any user-controllable code has been executed, and goroutines get mapped arbitrarily to OS-level threads by the runtime (there's an option to pin a goroutine to the thread it is currently in, but not to a specific thread, IIRC), meaning that anything that is set at the thread level in UNIX is effectively unavailable to you in your current process.
In light of that fact, and in light of the fact I see no code here, I remain unsure how the original poster actually has integrated pledge into Go.
The only C code I have under my maintenance is code whose sole purpose in life is to be run as setuid, take some command line arguments, open some privileged files, start a known executable, and pass the file handles to that executable directly, so the unprivileged user running the executable can not see the contents of those files. (The system is locked down in other ways too, e.g., the users can not run strace to see the contents, LD_PRELOAD is locked down, etc., and as the final defense against internet rando systems designers criticizing this design on the basis of a single sentence, it's not the only line of defense here either.) I would _prefer_ to use Go, but there's no safe way to drop privileges in a Go executable, and for various technical reasons the exec support in Go does not _quite_ cut it. (It is close, but no cigar; we can not quite specify all the details we need from the outside.)
Someone|2 years ago
Of course! I think the chance of that happening must be about 100%. When else would it start such threads?
It would be an interesting bug if somebody managed to get a garbage collector thread to read files or to make network requests fo them…
jerf|2 years ago
It has mostly died down but a segment of the developer community took great exception to the designers of Go calling it a "systems" language when it had GC, which, as everybody knows, makes it worthless for all tasks ever. (Sarcasm.) However, in my experience, the bigger problem with it as a "systems language" is that the runtime has already spawned off threads by the time the first line of any user-controllable code has been executed, and goroutines get mapped arbitrarily to OS-level threads by the runtime (there's an option to pin a goroutine to the thread it is currently in, but not to a specific thread, IIRC), meaning that anything that is set at the thread level in UNIX is effectively unavailable to you in your current process.
In light of that fact, and in light of the fact I see no code here, I remain unsure how the original poster actually has integrated pledge into Go.
The only C code I have under my maintenance is code whose sole purpose in life is to be run as setuid, take some command line arguments, open some privileged files, start a known executable, and pass the file handles to that executable directly, so the unprivileged user running the executable can not see the contents of those files. (The system is locked down in other ways too, e.g., the users can not run strace to see the contents, LD_PRELOAD is locked down, etc., and as the final defense against internet rando systems designers criticizing this design on the basis of a single sentence, it's not the only line of defense here either.) I would _prefer_ to use Go, but there's no safe way to drop privileges in a Go executable, and for various technical reasons the exec support in Go does not _quite_ cut it. (It is close, but no cigar; we can not quite specify all the details we need from the outside.)