Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!rice!sun-spots-request From: auspex!guy@uunet.uu.net (Guy Harris) Newsgroups: comp.sys.sun Subject: Re: making fingerd non-root Message-ID: <812@auspex.UUCP> Date: 13 Jan 89 09:51:53 GMT References: <587@uva.UUCP> Sender: usenet@rice.edu Organization: Sun-Spots Lines: 33 Approved: Sun-Spots@rice.edu Original-Date: 6 Jan 89 22:36:12 GMT X-Sun-Spots-Digest: Volume 7, Issue 100, message 6 of 11 >Making fingerd setuid to some 'innocent' user won't help. > >The man page for execve states: If a program is setuid to a non-super-user, >but is executed when the real uid is 'root', then the program has the >powers of a super-user as well. The caveat is somewhat confusing. I presume what it's trying to say is that the program has *some* of the powers of a super-user and can, if it chooses, obtain more of them. A few places in the kernel check either for effective *or* real UID being 0 (I don't remember which ones, offhand), and if the real UID is 0 the program can set its effective UID to match its real UID and thus get super-user privileges. Either that, or it's describing a state of affairs that was true in older versions of UNIX, but that is neither true in 4.xBSD nor System V, and thus not true in many (most?) of the UNIXes around today. Back in V7, if the super-user ran a set-UID program, the process running the program was not made set-UID; this is not the case in more modern UNIXes - the process is made set-UID just as if a user other than the super-user ran it. In any case, if you have a program that is set-UID to some user ID that does not have permission to read some file X, and the super-user runs that program, the program will not be able to open file X for reading unless it sets its effective UID to match its real UID (i.e., root). I tried this on a 4.0 system with a set-UID "cat" (which doesn't set its effective UID to match its real UID), and it is indeed true. [[ This was sent in later: --wnl ]] More precisely, the man page states (in the SunOS 4.0 and 4.3-tahoe manual) that the program has *some* of the powers of a super-user. This is, as I mentioned, true, but the powers in question do not include the power to read arbitrary files.