Subject: Re: Setreuid not working as specified in NetBSD 1.0/i386
To: John Kohl <email@example.com>
From: Tom Pavel <pavel@MAILBOX.SLAC.Stanford.EDU>
Date: 08/11/1995 17:49:38
>>>>> On Fri, 11 Aug 1995, John Kohl <firstname.lastname@example.org> 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,
Stanford Linear Accelerator Center