In message <Pine.NEB.4.21.0011270937350.13212-100000@gandalf.starwolf.com> Greywolf writes:
: # Perhaps, instead of your magic_next_syscall(); open(...); and doing 
: # bookkeeping to make it behave atomically, we actually make it atomic
: # and end up coding either magic_open(magic_data, open_arg_0, open_arg_1, ...)
: # or magic_syscall(magic_data, open, open_arg_0, ...), either of which
: # traps immediately to the kernel.
: 
: I think the point kre's trying to make, here, is that there is no real
: need for the suggested mechanisms (which are trying to nail three
: different issues with one brick).

I've been trying to make that point to.  Given a little care, and the
banning of setreuid() we can solve the "open the file with the wrong
uid" problem.  Still leaves that "setuid programs that have buffer
overflows can set back their uid" problem, but that is a different
problem and should be solved in different ways.

: I.e., this whole thing has gone decidedly far afield of the course
: for which it was intended.

Agreed.

Warner