Austin Group Defect Tracker

Aardvark Mark IV

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 2024-06-11 09:02
Reporter eblake View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Closed  
Name Eric Blake
Organization Red Hat
User Reference ebb.setreuid
Section 2.4.3 Signal Actions
Page Number 494
Line Number 16845
Interp Status ---
Final Accepted Text
Summary 0000699: setr?e[gu]id should be async-signal-safe
Description 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.
Desired Action 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
Tags issue8
Attached Files

- Relationships

-  Notes
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.

- Issue History
Date Modified Username Field Change
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
2024-06-11 09:02 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker