>>>>> "Curt" == Curt Sampson <curt@portal.ca> writes:

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

Most of the uses of setreuid() I've seen want to change the effective
UID while retaining the ability to put UIDs back to the way they were
before the program called setreuid().  For example, some setuid root
programs want to create a file owned by the user who ran the program
(rather than having root own the file).

If this is what Taylor UUCP wants to do, you can probably do what you
want with the seteuid() call--this is a 4.4BSD-ism as well, but it's not
in POSIX.  You could define routines like:

priv_on() { seteuid(privileged_uid); }
priv_off() { seteuid(unprivileged_uid); }

and call them as appropriate.  If you want to permanently change your
UID then use setuid(), of course.

See C-Kermit 5A(190) code in ckuuid.c (test program--quite handy to
probe your system's implementation) and ckutio.c (kermit code).  Look
for the CPP symbol SETEUID.

==John