Probably, I'm missing context (unfortunetely, I don't have time to
read all mails), but...

>>>>> On Thu, 16 Nov 2000 17:24:51 -0700, Warner Losh <imp@village.org> said:

imp> I've had really off the wall suggestions sent to me for fixing the
imp> kernel:
imp> 	Have a "half open" that will open the file without really
imp> 	opening it.  One that does just the permissions checks and
imp> 	nothing else.  Then have a 2nd have of the open that completes 
imp> 	the open.  This is similar to access, except it gives you
imp> 	a handle that you can fstat with, as well as later open w/o
imp> 	a race no matter how long you take to get around to it.

imp> 	Have a flag that says "open only normal files" or "don't open
imp> 	devices" like was suggested in the NetBSD lists.

imp> 	Implement linux's fsetuid()

Why do you ignore the following option?

	Deprecate setreuid(2) and setregid(2).
	Use saved-uid/gid feature to drop privilege.

Half-open, open-only-normal-files, fsetuid, open_as are all insufficient,
because there are system calls other than open(2) which is related to
user's privilege.
The saved-uid/gid feature can do what those can do, and can cope with
system calls other than open(2), too.

>>>>> On Mon, 20 Nov 2000 16:35:34 +0100 (CET),
	Jaromir Dolecek <dolecek@ics.muni.cz> said:

dolecek> There is the problem with setreuid(), which can cause the "real" id
dolecek> is switched with effective id, so it's no longer possible to find
dolecek> out "real" real id. Some people think we should babysit
dolecek> broken suid programs which use the syscall.

Mmm?
Who think we should babysit the broken suid programs?

As far as I know, mycroft, mrg, and other all developers agreed that
we whould deprecate setreuid(2).

Of course we cannot remove setreuid(2)/setregid(2) from our libc
(unless we bump major number of libc), but that is not problem to
deprecate those functions. We can declare that programs which use
setreuid(2)/setregid(2) are broken just like programs which use
gets(3) are broken.
Our libc still contains working gets(3), but our userland is free from
gets(3). We can do just same thing for setreuid(2)/setregid(), thus,
having working setreuid(2)/setregid(2) in our libc is not problem.
--
soda