> Yes this seems twisted at first glance, esp. since the process is
> trying to give up its setuid-ness.

And second glance, and third...the real problem is overloading the
saved-set-id.

> However, given the unix-like systems base their entire security
> policy on the set-user-ID-on-exec feature, and the fact that there is
> but one privileged user (i.e. uid==0),

This isn't true, actually.  gid kmem is privileged, the uid that owns
the "system" executables (typically "bin") is privileged, "games" is
privileged...not by any property of the kernel, but simply because the
system is set up so that those IDs are empowered to do things that
ordinary users cannot.

>> if i have a program that i want to have "some" privileges (ie, it
>> can read a file owned by user `foo'), i make it set-uid (to user
>> foo).  if, after i've read this file, i decide, being a security
>> conscience coder, that i no longer need the ability to read this
>> file [...], i want to revoke these priviledges.

> The first trivial fix is to just call setuid(getruid()); and remember
> never to call setuid() again.

This leaves you wide open to anything that tricks the process into
executing code you didn't write (stack-smash bugs are the commonest
example); this is exactly _why_ a security-conscious coder will want to
completely revoke all privilege, to limit the damage such a bug can do.

>> NetBSD is extremely close to being POSIX.1 compliant. There are a
>> few nits we know about: some we plan to fix, and others we plan to
>> ignore until a future revision of POSIX.1 ``fixes'' them for us.

> [...] I doubt there's any hope of POSIX.1a ever "fixing" this
> particular "non-problem".

But it isn't a non-problem.  Go read my other message, explaining what
exactly is wrong with the POSIX model and why it's a problem.  I, for
one, am squarely behind core in their decision to ignore this
non-compliance (if such it in fact is) until POSIX gets it right.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu