> I don't use seteuid(), but, it looks like you can just re-swap the > (uid, euid) in a child binary and regain the parent's privileges.
Probably. What does that have to do with what I was after? In my case, the process forks but does not exec; there is only one executable involved. I didn't explain _why_ I reached for setreuid. I have been working on a new kernel facility - basically, something a bit like sockets, but using PIDs as addresses. (I first started out planning on adding AF_PID sockets, but it turns out that, at least in the version I've been working under, that's not suitable - the AF-independent socket machinery does too much. In particular, it keeps a queue of pending connections per socket, and has no way to differentiate between two processes with file descriptors on the same socket. So I'm using DTYPE_MISC, my own f_ops vector, and a dedicated syscall. But, except as my motivation for wanting setreuid(), that's off-topic here.) One thing I wanted to add was something a bit like LOCAL_PEEREID. To test it, I wanted two processes, each with a distinctive ruid and euid (four different values across the two processes). I couldn't see any way to achieve this with less than setreuid() - at least not without creating an executable setuid to one of the IDs and then running it from the other, and the repeating all that for the other two UIDs. This would have been seriously inconvenient, especially as compared to setreuid(). The only issue, turns out, was that the manpage overstated the degree to which setreuid() is obsolete. I tried to file a PR about that, but the mail bounced, apparently looping inside NetBSD mail infrastructure. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
