Re: the watchdog of login program

[Roland McGrath]

> We should be very careful about changing this.  But if we change it
> only for the actual term program, it might be harmless.

Yes, I was only talking about term's virtual node, and not transmitting the
changes to the underlying node on disk so it could be abused.  Even so, I
think the thing to do is restrict it so that essentially login gets to do
it but noone else.  

> More exactly, you mean before calling proc_setowner.

Yes.

> We should be more careful here.  

How?

> There might well be more ports than this.  

Like what?

> For all we know, we have big giant hairy port leaks in the startup code
> for the Hurd, and every process in the system is running as root.

Not if there are EXEC_NEWTASK execs involved.  

Like I said, there might be leaks in login I haven't though of.  Using
EXEC_NEWTASK is the way to be sure none survive, but there will be a window
between proc_setowner and the exec completing where the target owner can
hijack the login process and exploit any leaks.  We can avoid that by using
EXEC_SECURE instead, and just not calling proc_setowner at all.  Then exec
will use proc_setowner on the fresh task's proc port after proc_reassign.

> But the solution to that is I think two fold: making proc and such
> programs drop all their Mach state before calling proc_setowner, by
> running through the ports that the kernel says we own.  (Perhaps this
> hair should all be in a library function, since su and friends need it
> too.)  Startup programs should maybe do a similar exercise at
> judicious places.

That is nuts.  You don't know what you are talking about proc and startup
programs for.  There is no problem with them.  We are talking about login here.