The following issue has been SUBMITTED. ====================================================================== https://www.austingroupbugs.net/view.php?id=1344 ====================================================================== Reported By: mkerrisk Assigned To: ajosey ====================================================================== Project: 1003.1(2008)/Issue 7 Issue ID: 1344 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Michael Kerrisk Organization: man7.org User Reference: Section: XSH Page Number: n/a Line Number: n/a Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2020-05-20 10:34 UTC Last Modified: 2020-05-20 10:34 UTC ====================================================================== Summary: Addition of setresuid()/setresgid()/getresuid()/getresgid() Description: setresuid()/setresgid()/getresuid()/getresgid() are implemented on a number systems including at least Linux, FreeBSD, OpenBSD, and HP-UX. (Notably, they are not present on Solaris, so far as I know.)
Adding these interfaces to POSIX would be valuable for a number of reasons: * The semantics of the existing APIs for modifying credentials are problematic. The semantics of setuid()/setgid() depend on whether the process is privileged, so that the API either changes just the effective ID, or all of real/effective and saved set IDs. The only POSIX-specified way to change saved set IDs is to use setreuid()/setregid(). But those APIs depend on a bizarre rule to determine whether or not the saved set ID is modified. These sorts of funny behaviors are invitations for programmers to make mistakes, and in this case such mistakes have obvious security implications. * By contrast with the former point, the semantics of the changes made by setresuid() and setresgid() are simple and transparent: one argument per credential, with "-1" being used to signify "no change". No semantics that vary according to whether the process is privileged and no funny rules. * getresuid()/getresgid() provide the only means of explicitly retrieving the save set-UID/GID. Desired Action: 1. Add specifications of setresuid()/setresgid()/getresuid()/getresgid() 2. Add SEE ALSO entries in relevant other pages (getuid(), geteuid(), setuid(), setreuid(), getgid(), getegid(), setgid(), setregid(), <unistd.h>) 3. Add prototypes to <unistd.h> 4. Add to "XSI_USER_GROUPS" in "E.1 Subprofiling Option Groups"(?) I will attempt 1; presumably 2, 3, 4 can be written up as boilerplate editing directions (which I can attempt, but may need some assistance). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2020-05-20 10:34 mkerrisk New Issue 2020-05-20 10:34 mkerrisk Status New => Under Review 2020-05-20 10:34 mkerrisk Assigned To => ajosey 2020-05-20 10:34 mkerrisk Name => Michael Kerrisk 2020-05-20 10:34 mkerrisk Organization => man7.org 2020-05-20 10:34 mkerrisk Section => XSH 2020-05-20 10:34 mkerrisk Page Number => n/a 2020-05-20 10:34 mkerrisk Line Number => n/a ======================================================================
