rdist/setreuid

Jim Balter jim at segue.segue.com
Mon Apr 1 08:25:36 AEST 1991


In article <6921 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
|>We ran into a problem while trying to port rdist from 4.3bsd to sysVr3.
|>rdist uses setreuid to switch back and forth between root and the user,
|>but sysVr3 (and even sysVr4 apparently) only has setuid; ie, once
|>you're the user, there's no going back to root.  Are we overlooking
|>something?  It's particularly surprising that sysVr4 also seems to
|>have this limitation.
|
|S5R4 may have, as an undocumented feature, a "seteuid()" call that, even
|if you're root, sets *only* the effective UID and leaves the
|saved-set-user ID alone.  I think the next POSIX 1003.1 supplement will
|mandate "seteuid()", so it shouldn't remain undocumented forever....

If only POSIX hadn't picked up the SysIII/V bug of setting the saved UID = uid
when root does a setuid(uid), thus making the feature useless for root.  The
saved uid should have reflected the uid after the exec, regardless of
subsequent calls.  Since the only point of the saved uid is to allow return to
the original effective uid after setuid(getuid()), changing it upon setuid() by
root is idiotic.  Sigh.

The only portable solution to this problem that I know of is to do the
setuid(getuid()) and the operations that require it inside a subprocess.
vfork is often sufficient.



More information about the Comp.unix.programmer mailing list