I find it fairly bogus that we implement these functions incorrectly.
I propose implementing them as specified in 4.3BSD, with three
additional changes to enforce the 4.4BSD security model:

1) If we change the real ID, also change the saved ID to the same
thing.  This provides a `downward slope'; you can use setreuid() and
setregid() as many times as you want, exactly as in 4.3BSD, but
afterwards you can only use setuid(), seteuid(), setgid() and
setegid() to change the effective ID to the real ID (which is also the
saved ID), and thus revoke any extra privileges you have.

2) Any places which compare the real and saved IDs to check whether a
process is still in a set-ID context (e.g. coredump()) must be changed
to also compare the effective ID.  This does not create any
unnecessary restrictions when only using the setuid(), seteuid(),
setgid() and setegid() functions, because the fact that the real and
saved IDs are the same means that the effective ID must also be the
same unless your real ID is root (in which case it's arguably a bug
that we currently allow core dumps).

3) Both functions must set P_SUGID to disable ptrace(2) and procfs.

Does anyone object to the preceeding changes?