Re: Task destruction

[Marcus Brinkmann]

On Tue, Aug 06, 2002 at 11:47:33AM +0200, Niels Möller wrote:
> > But if that second Hurd system runs privileged, it is in the same
> > position as the first Hurd system. [...] In any case, those two Hurd
> > systems should be symmetrical, and in a neighour position.
> 
> Right. That's even more true if all coordination of hardware access is
> done via "non-hurd" servers, without one of the hurds acting as a
> proxy for the other. The task server and the memory server can be
> viewed as two such servers. When it comes to access to other hardware
> (e.g. disks, or indivudual partitions on a disk), I've not seen any
> solution yet, but I'm sure something could be done if we want to push
> the neighbour model even further.

Well, currently the neighbourhurd gets a faked device master port with a
faked console device so that you can see the output of it in your shell.
If you actually had two console devices in the kernel (or whereever), then
we could make this dependency optional.

In fact, I think with my console server this is exactly what you can do.
We just need a generic solution to access a neighbourhurd filesystem, and
then you can use one console client to access multiple console servers (each
console server being the default console for one of the Hurd systems
running).  Of course, the console client itself would run in one particular
Hurd system, but you could change the one it's running in (by stopping and
restarting another one).

We would still use the faked console port for bootstrap, but after the
system got up and running, and the term server on /dev/console is
redirected, you could tear down the faked device master port in favor of the
real one (which is not passed through yet, but could be in case of a
privileged Hurd system).

> > If you look at the current implementation of proc, a proc running with
> > privileges will always display _all_ tasks in the system and assign a pid to
> > them.  This pid is unique to this proc server.  Unregistered tasks will
> > just get a pid, so you can kill them.
> 
> Exactly what attributes do the unregistered tasks get, besides the
> pid?

They get init as their parent, until we have implemented task inheritence in
Mach (well, in L4 it would be the task server).  They get a flag that says
they are unowned, and their other properties are things like no login
leader, etc. (see proc/mgt.c complete_proc())

> In particular, who is allowed to kill them, or control them in a
> debugger?

Only root for now.  If we could identify the parent task via the anonymous
inheritance handle, we could change that.

> To me it seems that if we want the "every task is a process"
> model, we at least have to associate some uid to the task.

Uh, no.  You are ignoring the existing implementation, which has the "every
task is a process" model and still doesn't assign an uid to all tasks, not
even to all registered tasks.  You can create unowned completely autonomous
processes in the Hurd (for example, run a process as the no-user, and put it
in its own login session).

> And it gets
> even more complicated if you take login groups into account (where uid
> is not enough). The "responsible process" model seems a little more
> robust to me, but I should perhaps not argue strongly for it at this
> point. Perhaps we should call it "parental guidance"? ;-)

I think all we need is tracking of the anonymous handle in task inheritance,
and make changing the handle a privileged operation.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/