Third try at setuid help ... - S5+4.2 >> S5 or 4.2 individually

[Guy Harris]

> (4.2BSD "ftpd" can switch its effective UID between 0 and some user's UID,
> since you can set the effective UID without affecting the real UID in
> 4.2BSD; this doesn't work in S5.  In 4.2BSD this is no problem, due to
> the setreuid mechanism.  But what about System V?  We really don't want
> to have to shoehorn setreuid into System V (due to large
> changes over Version 7 setuid, among other things), but ...

S5R2 has two separate system calls to set UIDs.  One sets the real,
effective, and "original-set-UID" UIDs to some value, and one sets the
effective UID either to the real or "original-set-UID" UID.  The first is
for the benefit of set-UID programs which want to repeatedly switch between
the user who ran them and the user they're borrowing the privileges of, and
the second is for the benefit of "login" and the like.  Unfortunately,
they have the same system call number and calling sequence, so they needed
some other way to disambiguate them.  They chose the following crock:

	IF you give "setuid" a non-zero value *and* it's either the
	same as the real UID or the "original-set-UID" UID, it's the first
	call, otherwise it's the second.

A better approach would have been to provide "setreuid".  All you really
have to do is put in "setreuid" and have "setreuid(-1, euid)" act like the
first kind of S5 "setuid".

Also note that the S5 rules for "ownership" of a process are different.
"u.u_procp->p_uid" still represents the "owner" of a process, but "p_uid" is
now the *real* UID, not the effective UID.  "p_suid" is normally the same as
"p_uid" unless you execute a set-UID program, in which case it's the UID the
program was originally set-UID to (this does not follow the effective UID,
so you can relinquish set-UID privileges and still grab them back).

This "owner" is used when "fork" checks that a particular UID doesn't have
more than the system per-UID process limit's worth of processes - using the
real UID seems to make more sense than using the effective UID, since you
don't really want set-UID games and the like to count against the owner of
the game; it should count against the person running the game.  However, a
daemon like "uucico" should count against "uucp", not the person running it;
to do this, you just need to permit "setreuid" to set the *real* (and,
presumably, original set-UID) UID to match the *effective* UID.  (Also note
that 4.2BSD disk quotas work against the real, not the effective, UID; this
also requires you to be able to set the real UID, since "uucico" should
charge against "uucp"s quota, not the quota of the poor schnook who happened
to trigger off the "uucico".)

Also, in S5 a process can send a signal to another process if its real *or*
effective UID matches the real *or "original-set-UID" UID of the target.  In
order for a set-UID process like "uucico" to protect itself against being
blown away by the aforementioned schnook, it needs to set its real and
"original-set-UID" UID to its effective UID (i.e., "uucico").

In summary, S5 and 4.2 should have compatible UID handling.  4.2 (or 4.3)
should pick up the change in the "ownership" of the process, the ability to
switch repeatedly between real and "original-set-UID" UIDs, and probably the
looser process killing rules; S5 should pick up "setreuid" and the ability
to set the *real* (and "origina-set-UID") UIDs to the *effective* UID.
(4.2's "setuid" should still do "setreuid(uid, uid)", and S5's should still
work the way it currently does, for backwards compatibility; future code
should use "setreuid", or "seteuid", or "setruid", which will be compatible
between both systems.  Ultimately, the S5 "setuid" should be deprecated in
favor of 4.2's.  Obviously, with a name like "setuid" it should set *both*
UIDs.  If you wanted to set only the effective UID, you should have used
"seteuid", as the name suggests.)

> PS:  Does anybody know why the System V.2 setuid(2) man
> page has so little to do with reality?  It is a LARGE
> change over previous versions, and does not agree at
> all with the code.  The reason I ask is that if setuid
> really worked the way the man page says, we would have
> no problem!

Why does it have so little to do with reality?  What's the name of the OS
we're dealing with here?  UNIX, of course; it is rumored that the universe
will come to an end if a set of UNIX manuals which completely and correctly
documents the behavior of its corresponding UNIX system is ever issued.  At
the rate things are going, the Indian priests doing the 64-disk Tower of
Hanoi will finish up and destroy the universe before that UNIX manual ever
comes out...

The System V Interface Definition is closer to the truth, but still not all
the way there.  I suspect that nobody told the documentation people the
truth in time for the S5 manuals.

	Guy Harris