guy@sun.uucp (Guy Harris) (11/09/85)
> (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