Path: utzoo!utgpu!cunews!micor!latour!ecicrl!eci386!woods From: woods@eci386.uucp (Greg A. Woods) Newsgroups: news.software.b Subject: Re: C News and setuid(geteuid) Message-ID: <1991Feb8.025135.6045@eci386.uucp> Date: 8 Feb 91 02:51:35 GMT References: <1991Feb2.060633.23602@zoo.toronto.edu> Reply-To: woods@eci386.UUCP (Greg A. Woods) Organization: Elegant Communications, Inc. Lines: 47 In article <1991Feb2.060633.23602@zoo.toronto.edu> geoff@zoo.toronto.edu (Geoffrey Collyer) writes: > Years ago, when relaynews was written, it appeared that all modern Unixes > were permitting setuid(geteuid()) and doing the obvious and sensible > thing. Alas, that was before the SVID and SysV (and now POSIX) went mad > and started inventing saved-userid-at-exec and other cracked schemes for > muddying a previously clean and simple mechanism for the sake of some > ill-defined and small class of problems. We don't have many pure System > V's around here, since our machines tend to need TCP/IP and Ethernet > support, so it's hard to be sure just *what* a modern System V does with > setuid(geteuid()), but judging from the complaints we have had, it > doesn't set the real uid (i.e. it botches the setuid() call) or getuid() > doesn't return the real uid (a different botch). Well, just to pick a nit, the problems "solved" by the SVID specified behavior of setuid() are very well defined, and quite real. Specifically, without "saved user(group)-id at exec", accountability is not achievable. In addition, the new behavior allows a process to switch between its real and effective user(group)-id without starting with an effective uid of 0, and without forking. Some will argue that none of these features are necessary.... And, in fact it is quite clear from the SVID exactly what modern SysV does with setuid(geteuid()). In addition I argue that the SVID mechanism is quite clean and elegant, and is certainly much more so than the mess in BSD-4.2. It is also more upwardly compatible. The real botch was with the failure to provide a mkdir() call simultaneously with the new setuid() behavior (though this was fixed with the release of SVID Issue 2 and SysVr3.0). BTW, though the SVID was published in 1986, I've just peered at a copy of the XENIX 3.0 setuid()/setgid() manual page which was printed in 1984. It is almost identical to the SysVr3.0 (1988) manual page. (SysVr3.0 adds an error return EINVAL for uid or gid being out of range.) (This version of XENIX did not have a mkdir() either.) I would seem to me to be quite logical to assume that if UNIX 3.0 (and thus XENIX 3.0) had this "new" behavior, it would be around for some time, though I suppose one might have ignored logic if one didn't want UNIX 3.0 to survive. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL