(0001617)
dalias (reporter)
2013-05-18 14:34
|
I agree that this change is desirable, but presently on Linux-based systems, not even setuid/setgid are async-signal-safe, despite the standard requiring them to be. Moreover, it seems almost impossible to make them async-signal-safe, since the Linux kernel insists on keeping uids/gids thread-local, while POSIX requires them to be a property of the process, and the only way to resolve this discrepancy is for the library implementation to synchronize uid/gid switching between all threads. Current implementations of this approach, both the original one in glibc and the somewhat different one in musl libc, depend heavily on locking. I've been aware of this issue for some time, and I have been researching whether there's a way to implement this without locking, but so far I have not found any suitable solution.
I'm not sure what the right answer with respect to the standard is. Presently, setuid and setgid are NOT async-signal-safe on a major implementation and there's no indication that it's feasible to make them safe. From that standpoint, I think it would be a mistake to add the other uid/gid functions to the async-signal-safe list when the current ones aren't even async-signal-safe in practice.
On the other hand, I agree that it's highly desirable to be able to use all of the uid and gid setting functions between fork and exec.
One possible solution would be to add these functions, but also add a note that none of them need be async-signal-safe in a multi-threaded process. Perhaps they should even be added to the list of functions which are not thread-safe, since changing the uids/gids of a process from multiple threads is a very bad idea to begin with, from a security design standpoint if nothing else. |