3 ms·

Actually that is exactly the case in a library of mine[0]. Its not a bug of my code directly but due to non-POSIX compliance of Linux that triggers only with mu

Actually that is exactly the case in a library of mine[0]. Its not a bug of my code directly but due to non-POSIX compliance of Linux that triggers only with multiple threads (setuid does set the uid only for the executed thread and not for the others of the same process - unlike the manual page and POSIX states). Its a cornercase but I also explicitly raise the GOMAXPROCS in the test case to trigger it[1]. [0] https://github.com/sarnowski/mitigation https://github.com/sarnowski/mitigation [1] https://github.com/sarnowski/mitigation/blob/master/mitigation_test.go https://github.com/sarnowski/mitigation/blob/master/mitigati...

saurik 12y ago
(context for others, where you reported this) https://code.google.com/p/go/issues/detail?id=1435 https://code.google.com/p/go/issues/detail?id=1435 It is fair to claim that this is "non-POSIX compliance of Linux": the underlying system call interface of an operating system is not something subject to a standard. The mapping from the POSIX-compliant C library to the underlying system calls is allowed to be quite complex, and in fact most of the high-level POSIX functions map to system calls designed for much more general use cases, or arguments with different kinds of struct packing. You really just should not have been coding directly against the system calls of the operating system: that isn't portable; and later in the discussion, this was specifically addressed ("The syscall package is not for general use. It has no documentation. That's not going to change. When we have a working Setuid etc they will be made available as part of package os."). What sucks is that they seem to have never gotten around to implementing os.Setuid.