Xref: utzoo comp.unix.wizards:15223 comp.bugs.sys5:821
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards,comp.bugs.sys5
Subject: Re: setuid (euid) after setuid (uid) on System 5
Message-ID: <8033@chinet.chi.il.us>
Date: 25 Mar 89 21:08:58 GMT
References: <123@cat.Fulcrum.BT.CO.UK> <280@cbnewsc.ATT.COM> <1196@auspex.UUCP> <13416@steinmetz.ge.com>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Followup-To: comp.unix.wizards
Organization: Chinet - Public Access Unix
Lines: 20

In article <13416@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>
>  The setuid behavior gets to be a real pain in the case where a program
>is running setuid (not root) and needs to run another program to perform
>some task. The execed program runs with its uid and euid set to the uid
>rather than the euid, and there's no reasonable way to change this, such
>as setuid(geteuid()) in BSD.

I've had similar problems trying to bundle files with cpio and using
uux to restore them at other sites.  The problem is that cpio runs
/bin/mkdir (even under SysVr3 where it doesn't have to) to create
any needed directories, and /bin/mkdir decides that the owner should
be the real uid.  The real uid of uux is likely to be anyone who
recently sent mail, so the next time something is delivered to that
directory, uux (same euid, different real uid) can't write there.
The only way I can make this work without putting setuid programs
on other people's machines is to make sure all the directories are
writable by everyone before cpio'ing them.

Les Mikesell