>Curt> Unfortuately, it seems that setreuid() doesn't set the real user ID
>Curt> as it's supposed to, or at least doesn't do it in a way that makes
>Curt> getuid() return the correct value. I can swap the two IDs back if I
>Curt> give it the original euid, but I don't get that original euid back from
>Curt> getuid():
>
>Curt> So, basically, I'm confused. Is this behaviour of NetBSD (not really
>Curt> setting the real uid) acceptable (i.e., should programs like Taylor
>Curt> uucp be saving the euid and resetting that, rather than relying on
>Curt> getuid() to return the old euid after a swap)?
>
>It's a 4.4BSD-ism that you cannot change the real UID except via
>setuid(), and when you do use setuid() there is no going back to any
>previous real or effective UID unless you've just setuid()'d to root.
>[I vaguely recall the rationale for this was related to POSIXisms, but I
>don't know for sure.]

My understanding is that the real UID is nearly always supposed to refer
to the "real" UID; that is, the UID of the person at the keyboard (or the
original UID before any setuid bits applied).

In that sense, the real UID is only supposed to change when you "become"
someone completely - this is what setuid() is for, and is a one-way operation.

I was under the impression that seteuid() _was_ POSIX, but John says not, so
I'm willing to believe him :-)

--Ken