In message <20001103105841.A28880@mail.netbsd.org> Thor Lancelot Simon writes:
: > this is the only solution i really can stomach, and it's taken me 3 years
: > to get to that point...
: 
: I think the right solutions are either capabilities or "open_as".  I 
: really, really don't like the idea of implementing zillions of 
: special-purpose "uid"s.

I think that open_as is too narrow in focus.  What about link/unlink?
what about all the other operations that are done on the file
systems.  open_as just fixes a narrow case.  I do agree that fsetuid
is a kludge, but it is the least gross way I've seen ofdealing with this.

: Generally speaking, file-descriptor passing is a solution to this kind of
: problem.  Unfortunately, it is difficult to persuade others to rewrite 
: their code to use it.

Yes.  It is easy to just set the setuid bit :-(

Of course, I've still not seen a case where the following wouldn't
work.
		/* at this point we have euid, ruid and saved-user-id */
	eid = geteuid();
	seteuid(getuid());	/* euid = ruid */
	/* do it */
	seteuid(eid);		/* restore euid */

As far as I can see it, there are a few cases:
	non-setuid: nothing happens, it just works.
	setuid, no setuid before thispoint:
		effective uid is changed to the user running this program
		open is done
		privs restored to what we were before
	setuid() done before this point:
		privs not dropped, but it is impossible to know how to
		do that since we have no knowledge of the old uid.
	seteuid() done before this point,
		Should be ok.  We get the real id, set it to that and
		then restore the old euid.

Of course this assumes that setgid privs aren't interesting, but
similar code could be inserted for that.

Please tell me what I'm missing.  This stuff always gives me a
headache.  I've seen this suggested many times, but have never seen a
cogent explaination about why this is broken that didn't have flaws in
the explaination.

Warner