glenn@suphys.physics.su.OZ.AU (Glenn Geers) (02/18/91)
Hi, I've got a program that is setuid root that runs a system command via the system(3) library routine. The problem is that I need the effective uid of the calling program to be inherited by the process run by system(3). Esix does not seem to do this. If I use my own fork/exec sequence I have no problems. The question is: Should system(3) really set the uid of the process it runs to the effective uid of the invoking program or to its real uid? I have RTFM'd and the former case seems correct but the latter is occuring. Any thoughts appreciated. Thanks, Glenn glenn@qed.physics.su.oz.au -- Glenn Geers | "So when it's over, we're back to people. Department of Theoretical Physics | Just to prove that human touch can have The University of Sydney | no equal." Sydney NSW 2006 Australia | - Basia Trzetrzelewska, 'Prime Time TV'
walter@mecky.UUCP (Walter Mecky) (02/25/91)
In article <1991Feb17.214252.27336@metro.ucc.su.OZ.AU> glenn@suphys.physics.su.OZ.AU (Glenn Geers) writes:
< I've got a program that is setuid root that runs a system command
< via the system(3) library routine. The problem is that I need the effective
< uid of the calling program to be inherited by the process run by system(3).
< Esix does not seem to do this. If I use my own fork/exec sequence I have no
< problems. The question is: Should system(3) really set the uid of the process
< it runs to the effective uid of the invoking program or to its real uid?
< I have RTFM'd and the former case seems correct but the latter is occuring.
I suppose the bad guy is not system(3) but sh(1). system(3) is calling
/bin/sh and I think in the mentioned fork/exec approach Glenn execed the
program directly not throuh /bin/sh.
I can not speak for ESIX, but in my system (SCO UNIX) this is a
(not documented) fact:
sh resets the effective uid back to the real
uid if they are different and the EUID != 0.
I noticed this in ISC 2.02 too.
Ugly, very ugly, I think, not only because it's undocumented but it
annoys the responsible programmers as Ken (and me) for the sake of
some careless ones.
--
Walter Mecky [ walter@mecky.uucp or ...uunet!unido!mecky!walter ]chip@tct.uucp (Chip Salzenberg) (02/25/91)
According to walter@mecky.UUCP (Walter Mecky): >I can not speak for ESIX, but in my system (SCO UNIX) this is a >(not documented) fact: > > sh resets the effective uid back to the real > uid if they are different and the EUID != 0. > SCO support has confirmed that /bin/sh doesn't like EUID and UID differing, and attempts to "correct" the matter. Double bleh.
john@jwt.UUCP (John Temples) (02/27/91)
In article <27C93418.F26@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >SCO support has confirmed that /bin/sh doesn't like EUID and UID >differing, and attempts to "correct" the matter. Double bleh. I don't think this is the source of the problem with ESIX. If I do { setuid(0); exec("/bin/sh", ...); } I get a root shell. If I do a { system("id"); } I get uid=me, euid=me if the program is setuid root; but I get uid=me, euid=him if the program is setuid to non-root "him". The system() call appears to zap the euid only if it's 0; sh seems not care. The same holds under ISC, incidentally. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
walter@mecky.UUCP (Walter Mecky) (02/28/91)
In article <1991Feb27.023816.10043@jwt.UUCP> john@jwt.UUCP (John Temples) writes: < In article <27C93418.F26@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: < >SCO support has confirmed that /bin/sh doesn't like EUID and UID < >differing, and attempts to "correct" the matter. Double bleh. < < I don't think this is the source of the problem with ESIX. If I do < { setuid(0); exec("/bin/sh", ...); } I get a root shell. If I do a < { system("id"); } I get uid=me, euid=me if the program is setuid root; < but I get uid=me, euid=him if the program is setuid to non-root "him". < The system() call appears to zap the euid only if it's 0; sh seems not < care. The same holds under ISC, incidentally. Stop! setuid(0) sets uid *and euid to 0. Thus /bin/sh can do no dirty things. To clear things up, the following program: main() { execl("/bin/sh", "sh", "-c", "id", (char *)0); } gives same results in SCO UNIX and ISC 2.2. It is compiled and placed in this files: -rwsr-xr-x 1 root group 15063 Feb 28 01:43 /tmp/t1 -rwsr-xr-x 1 peter group 15063 Feb 28 01:43 /tmp/t2 It shows, that in these two systems it's /bin/sh and not system() which manipulates the euid: $ id uid=200(walter) gid=50(group) $ /tmp/t1 uid=200(walter) gid=50(group) # /bin/sh resets euid $ /tmp/t2 uid=200(walter) gid=50(group) euid=203(peter) # now it doesn't Here the newest wisdom about the obscure sh: "/bin/sh resets the euid to the uid if the euid < 200" Somebody seemed to see uid below 200 as "system uids" and wanted to protect them with this obscure hack. sysadmin menus gives ordinary accounts uid >=200. -- Walter Mecky [ walter@mecky.uucp or ...uunet!unido!mecky!walter ]