Right.  That's why you really need to be able to drop privs, open the
   file, raise the privs.  Anything that doesn't allow this will be
   doomed to failure.
   
   Someone had said that there was an example of why seteuid() won't
   work, but so far haven't forwarded those examples to me.


OK, the reason here is that with setreuid(), the user can have set
either of these to any of the possible values available.  the policy
that was introduced by 4.4BSD "seteuid()" is essentially broken[*] by
the re-introduction of pre-4.4 setr*() calls, because it allows the
user complete access to both real and effective uid.  eg, when you
are in a library call, you have *no idea* which of the ruid or euid
is the one you want to use.  it may even be the case that they are
*both* the wrong one and the uid you *want* is really only in the
saved uid (not accessible by userland at all).  if you can prove to me
that this complete lack of knowledge is irrelevant, i will conceed :-)



[*] the "library" versions of these functions were considerably more
broken because they only gave the *appearance* of working.  i
personally would have prefer if the new seteuid()-style was the only
available set-id mechanism in NetBSD, and programs that wanted old
setr*id() calls would have to be changed, but i did not come to this
conclusion until years after these changes were made.