|Anonymous | Login||2023-03-31 00:41 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000699||[1003.1(2013)/Issue7+TC1] System Interfaces||Objection||Omission||2013-05-18 03:48||2020-03-24 15:53|
|Section||2.4.3 Signal Actions|
|Final Accepted Text|
|Summary||0000699: setr?e[gu]id should be async-signal-safe|
The standard already requires that setgid() and setuid() be async-signal safe; however, these two functions are inadequate to completely set all aspects of a process' identity when compared with the more powerful sete*id and setre*id variants. Yet, when writing a multi-threaded application, the only time at which it is possible to safely set the identity of a child process is either by the use of posix_spawn() (which is limited in what it can do), or between the fork() and exec*() of the child process (where it is only safe to use async-signal-safe functions). It makes no sense for the simpler function to be safe while the more complex function is unsafe, especially if the simpler one can be implemented in terms of the more complex one.
As a side note: The standard intentionally doesn't document initgroups() or setgroups(), but presumably initgroups() may have the same non-safety issues as getpwuid_r, while setgroups() would be async-signal-safe. Thus, a privileged application that can spawn child processes on behalf of another user would learn the uid, gid, and supplemental gids to use prior to forking, then change the identity of the child after forking.
At page 493, line 16845 [XSH 2.4.3 Signal Actions in the table of async-signal-safe functions], add the following in correct sorted order:
setegid seteuid setregid setreuid
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.
|2013-05-18 03:48||eblake||New Issue|
|2013-05-18 03:48||eblake||Name||=> Eric Blake|
|2013-05-18 03:48||eblake||Organization||=> Red Hat|
|2013-05-18 03:48||eblake||User Reference||=> ebb.setreuid|
|2013-05-18 03:48||eblake||Section||=> 2.4.3 Signal Actions|
|2013-05-18 03:48||eblake||Page Number||=> 494|
|2013-05-18 03:48||eblake||Line Number||=> 16845|
|2013-05-18 03:48||eblake||Interp Status||=> ---|
|2013-05-18 14:34||dalias||Note Added: 0001617|
|2013-05-23 16:12||msbrown||Status||New => Resolved|
|2013-05-23 16:12||msbrown||Resolution||Open => Accepted|
|2013-05-23 16:12||msbrown||Tag Attached: issue8|
|2020-03-24 15:53||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|