> Unfortuately, it seems that setreuid() doesn't set the real user ID
> as it's supposed to, [...]

> [I]n sys/kern/kern_prot.c find [...]:

>     /*
>      * we assume that the intent of setting ruid is to be able to get
>      * back ruid priviledge. So we make sure that we will be able to
>      * do so, but do not actually set the ruid.
>      */

Right.  This is a bug, since this is neither what NetBSD setreuid() is
documented as doing nor what setreuid() has traditionally done.  When I
noticed this, I squawked, but was told that it wasn't going to change
so get used to it.  It seems there is some (inexplicable, to me)
antipathy to making setreuid() actually do what it (a) is documented as
doing and (b) has traditionally done, to wit, change the real UID.  (In
-current, it's sys/compat/common/kern_prot_43.c, and the comment is
more verbose, but the behavior still disagrees with both traditional
setreuid() and the man page.  And in fact setreuid() the libc call no
longer calls that kernel routine, but rather does what the comment you
quote above describes, in user-land code.)

> So, basically, I'm confused. Is this behaviour of NetBSD (not really
> setting the real uid) acceptable (i.e., should programs like Taylor
> uucp be saving the euid and resetting that, rather than relying on
> getuid() to return the old euid after a swap)?

It is - obviously - acceptable to core.  I disagree; if they don't like
the behavior they should yank it out, not document it as doing what it
always has and then silently make it do something else.

It seems that the recommended way of doing this under NetBSD is just to
call seteuid().  They've implemented the saved-setuid-uid stuff, so
just using seteuid() works.  (If I might be permitted a minor rant: why
is it that whenever a standards group decides to fix something (which
usually isn't broken), they always _add_ complexity?!  We got stuck
with sessions, we got stuck with saved setuid uids....)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu