>>>>> On Fri, 11 Aug 1995, John Kohl <jtk@atria.com> writes:

> It's a 4.4BSD-ism that you cannot change the real UID except via
> setuid(), and when you do use setuid() there is no going back to any
> previous real or effective UID unless you've just setuid()'d to root.
> [I vaguely recall the rationale for this was related to POSIXisms, but I
> don't know for sure.]

> Most of the uses of setreuid() I've seen want to change the effective
> UID while retaining the ability to put UIDs back to the way they were
> before the program called setreuid().  For example, some setuid root
> programs want to create a file owned by the user who ran the program
> (rather than having root own the file).

> If this is what Taylor UUCP wants to do, you can probably do what you
> want with the seteuid() call--this is a 4.4BSD-ism as well, but it's not
> in POSIX.  


Granted the setuid()/seteuid() interface is a bit more intuitive than
the POSIX setuid() with _POSIX_SAVED_IDS (special casing on whether
real uid == root)...

But why don't we (also) implement the POSIX semantics for setuid()?
This would save people from having to write 3 sets of #ifdefs in their
setuid code (thus needing only POSIX and BSD < 4.4).  After all, isn't
this what the point of POSIX is, to be able to write portable code
without special cases for each unix flavor?  I could be wrong, but
couldn't we add an "if X==saved_uid (and process non-root), allow the
setuid(X) to modify euid to X" without changing the current uses of
setuid()?  What harm would this do?

Just a thought,


Tom Pavel

Stanford Linear Accelerator Center
pavel@slac.stanford.edu                 http://www.slac.stanford.edu/~pavel/