system(3) behaviour under Esix rev. D

[Walter Mecky]

In article <1991Feb27.023816.10043 at jwt.UUCP> john at jwt.UUCP (John Temples) writes:
< In article <27C93418.F26 at tct.uucp> chip at 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 at mecky.uucp	or  ...uunet!unido!mecky!walter ]