On Mon, 20 Nov 2000, Wolfgang Solfrank wrote:

# > There is the problem with setreuid(), which can cause the "real" id
# > is switched with effective id, so it's no longer possible to find
# > out "real" real id. Some people think we should babysit
# > broken suid programs which use the syscall.
# 
# Hmm, if someone writing programs and installing them setuid without
# knowing what he is doing, no amount of babysitting could help them
# (maybe apart from hindering them to type at a keyboard at all).

Now I think we're getting somewhere.

1. I don't think that babysitting errant setuid _programmers_ is our job.

2. Should the setuid/seteuid thing completely disappear as implemented
   in *BSD, or even as currently implemented in other versions of *NIX,
   we aren't even going to be *NIX-_compatible_, let alone *NIX-_like_,
   any more.

The whole POSIX thing about discarding the saved set uid if the user
is super-user is nothing but a band-aid which impedes any semblance
of flexibility with regard to switching UIDs if used as directed.
It's a band-aid because one can simply fork, setuid(), do their thing
and exit().

The reason that "set*id programs should contain the least amount of
code" is so that a fledgling to medium programmer Can't Fsck Sp.  This
is sensible.  I'd still like the ability to switch back and forth between
real and effective uids if necessary.

"But it shouldn't be necessary."

That is _entirely_ beside the point.  I think it should still be
*possible*, and I agree neither with the proposal of discarding setuid()
on a fork() by dictation, nor with the other proposal of resetting the uid
after every system call.  I still maintain it would be a nightmare, as
setuid() programs would not be able to use standard libraries (unless they
were rewritten in a major way, which would be a total paradigm redesign
on one of the lesser fundaments of the OS, if not the *NIX concept).

I will note, by the way, that if the real UID is 0 while the effective
one is not, you can get some strange things happening, for what it's
worth...I forget what they are ("Aw, he's just blowing smoke again!"
No, really!...), but I've seen them happen; permissions somehow denied
for one vnop while being granted for another; I think it was chown()
vs. chmod(), or maybe it was the ability to kill a process vs. a vnop.

Go figure.

# Ciao,
# Wolfgang



				--*greywolf;
--
*BSD: the power to swerve (penguins, worse than cane toads).