>> I find it fairly bogus that we implement [setreuid() and setregid()]
>> incorrectly.  I propose implementing them as specified in 4.3BSD,
>> with three additional changes to enforce the 4.4BSD security model:

> Your proposal seems OK, though I've not really drawn it out in detail
> so I can see all the implications.  My ony concern with any such
> features is that ideally it should not be possible for a process to
> go from root to some other user, then regain root privs.  This breaks
> the Orange Book C2 requirements.

I'm fairly sure mycroft's suggestion does not allow a process to do
that under circumstances when our current implementation would forbid
it, for what that's worth.  And depending on how you define your terms,
it may not allow it at all.

As I understand it, the "old" (=4.3) way is

	- Each process has a real uid (ruid) and an effective uid (euid)
	- It may set either one to match the other
	- It may swap them
	- Only if one of them is 0 are other changes allowed

And the "new" way is

	- Each process has three uids: real, effective, and saved (suid)
	- It may set euid=suid=ruid
	- It may set euid=ruid or euid=suid
	- Only if euid=0 are other changes allowed

The "proposed" way is

	a) Each process has three uids
	b) It may set euid=suid=ruid
	c) It may set euid=ruid
	d) It may set euid=suid
	e) It may set suid=ruid=euid
	f) It may perform (c) and (e) in parallel (old-style swap)
	g) When are other changes allowed?  Not clear, but not terribly
	    relevant at the moment - probably either when euid==0 or
	    whenever (euid==0)||(ruid==0).

Whether this upsets you according to the criterion you described
depends on what it means to "go [] to" a user.  If it means just that
euid is that user's, then all of these schemes will upset you, because
they all allow a setuid-root executable to run as the real user and
re-empower itself whenever it chooses.  (Nor do I think this is a bad
property.)  But all three schemes allow a process to permanently give
up its privilege by copying the ruid into all other IDs it has, at
which point there is no way back (unless the ID thus copied was 0).

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu