stanonik@nprdc.navy.mil (Ron Stanonik) (03/27/91)
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. Is there anything comparable to rdist for sysVr[34]? Thanks, Ron Stanonik stanonik@nprdc.navy.mil ucsd!nprdc!stanonik
guy@auspex.auspex.com (Guy Harris) (03/31/91)
>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.... (S5R4 apparently has a "setreuid()" call in the BSD compatibility library; whether any particular vendor supplies that library is up to them. I don't know how complete it is, and I think it's implemented, in part, atop "seteuid()"....)
jim@segue.segue.com (Jim Balter) (04/01/91)
In article <6921@auspex.auspex.com> guy@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.