5 ms·
As the article eludes to it is not without its challenges, however. As an example see this issue: https://github.com/golang/go/issues/1435 https://github.com/go
by btbuilder 8y ago
As the article eludes to it is not without its challenges, however. As an example see this issue: https://github.com/golang/go/issues/1435 https://github.com/golang/go/issues/1435 which goes into some of the details why implementing a call for setuid() is not straightforward without the knowledge built into glibc.
Also the trickiness of having efficient process fork/exec based on vfork: http://ewontfix.com/7/ http://ewontfix.com/7/
and the considerations going into Go: https://go-review.googlesource.com/c/go/+/46173/ https://go-review.googlesource.com/c/go/+/46173/
- pm215 8y agoI think for setuid in particular the right fix is for the kernel to provide a new syscall that operates on the whole process. The current hoops that glibc has to jump through with signals are complicated (and maybe racy? it's been a while since I looked at the code) and tie up a signal for libc's private use; better support at the kernel layer would allow that to all be eventually dropped.
- carapace 8y ago( allude (elude means escape))