Setuid(geteuid()), help

Maarten Litmaath maart at cs.vu.nl
Tue Jun 13 14:43:55 AEST 1989


tony at ajfcal.UUCP (Tony Field) writes:
\Is there any way to do a   setuid(geteuid())   when geteuid() != 0  ???

setuid() to either geteuid() or getuid() must ALWAYS succeed. Elementary.

\System: Xenix 2.2.3/386.
\
\I have a shell script that is running an effective uid of "news". The
\script calls a process that has a real uid of a "user". The process can
\create directories with mkdir that belong to "user", however it cannot
\create a file.

This is due to the new effective uid OVERWRITING of the old effective uid.
One might consider this a BAD feature...
Now let's take a look at `mkdir': I assume your version of Xenix doesn't have
the mkdir() system call, i.e. /bin/mkdir has to be setuid root.
Scheme:
			real uid - effective uid
	shell script	user       news
	> program 	user       news
	>> mkdir	user       root

whereas one would like
			real uid - effective uid
	shell script	user       news
	> program 	user       news
	>> mkdir	news       root

Alas! `mkdir' will chown() the directory to `user', notwithstanding `program'
having effective uid `news'!
On the other hand `program' (setuid `news') cannot create FILES in the
current directory, because the latter is owned by `user'.

\If the process is setuid to root, then I can create the directores and
\the files, however the owner becomes "root", and I would prefer the
\owner be "news". [...]

A solution: let the shell script invoke some `wrapper', which in turn
executes `program', AFTER having issued a setuid(geteuid()) to set the
REAL uid to the EFFECTIVE uid.
Scheme:
			real uid - effective uid
	shell script	user       news
	> wrapper	user       news
			 |
			 v
			news       news
	>> program 	news       news
	>>> mkdir	news       root

Of course `program' could do the setuid() as well.
-- 
"I HATE arbitrary limits, especially when |Maarten Litmaath @ VU Amsterdam:
   they're small."  (Stephen Savitzky)    |maart at cs.vu.nl, mcvax!botter!maart



More information about the Comp.unix.xenix mailing list