tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: setreuid(2)?
> 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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index