Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!killer!pollux!dalsqnt!rpp386!jfh From: jfh@rpp386.UUCP (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: System V.2.2 setuid() broken Message-ID: <3942@rpp386.UUCP> Date: 14 Jul 88 05:06:07 GMT References: <5968@umn-cs.cs.umn.edu> <2820@ttidca.TTI.COM> <58603@sun.uucp> <3475@sequent.UUCP> <59537@sun.uucp> <1305@basser.oz> Reply-To: jfh@rpp386.UUCP (The Beach Bum) Organization: Big "D" Home for Wayward Hackers Lines: 39 In article <1305@basser.oz> boyd@basser.oz (Boyd Roberts) writes: >I'm root and I run a non-root setuid executable. Then I want >to fork() a shell and do the usual: > > setuid(getuid()) > >Of course, I get EPERM, because setuid() is broken. Now is this >a generic System V bug. I think it is. Clarification please? no, according to SETUID(2), you got the correct behaviour, and on close examination, that is the CORRECT behavior. consider, running the a.out SUID sets the EFFECTIVE UID to the non-root user. getuid(2) returns the REAL UID which equals ROOT. and from the manual Setuid (setgid) will fail if the real user (group) ID of the calling process is not equal to uid (gid) and its effective user ID is not super-user. [ EPERM ] the real user ID is ROOT and the uid is ROOT. however, the effective user ID is not ROOT, so the call fails with EPERM. this `feature' prevents a trojan horse from doing a if (getuid () == 0) { setuid (0); chown ("/bin/sh", 0, 0); chmod ("/bin/sh", 04711); } thereby giving you the famed password free su command. - john. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes