bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: looking for the solution of rootless subhurd


From: Da Zheng
Subject: Re: looking for the solution of rootless subhurd
Date: Sun, 04 Jan 2009 19:20:17 +0000
User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

Zheng Da wrote:


On Mon, Dec 22, 2008 at 10:04 AM, <address@hidden <mailto:address@hidden>> wrote:


    > The point here is that the  process server needs to get all tasks in
    > the host,

    Yes, obviously it needs to. I understand your concern now, but I still
    don't see an actual problem...

The first problem is how to get the all of these task ports without root permission. The second one is how to get all tasks that belong to a specific subhurd. We can first just concern about the first problem for the moment.



    Note that the implementation of the pseudo master host port does not
    need to forward the RPCs directly to Mach. (In fact, it can't even do
    that, as it lacks the necessary privileges...) It can simply ask the
    main Hurd's proc server instead.

    I would hope that the proc server also has the necessary
    information to
    find out which tasks belong to the subhurd -- though I don't know for
    sure...

I just found there is the RPC proc_getallpids, so I can get all processes in the main hurd and then use pid2task to get their task port. I also found that pid2task only works for the tasks that belong to the caller. It almost solves my problem as long as the tasks created in subhurd belong to the user of subhurd in the eyes of the main Hurd.
I am afraid that it doesn't work. I mean boot cannot get all tasks in subhurd from the main Hurd's proc server. I guess the reason is that the tasks in subhurd cannot register themselves properly in the main Hurd's process server and the process server doesn't know who the tasks in subhurd belong to, and meanwhile, pid2task only works for the tasks that belong to the caller.
So we return to where we were: how to get all tasks in subhurd?
We have to choose: either get all tasks from the kernel or track all tasks in subhurd by boot. Again, I believe it's very dangerous to return all tasks in the kernel to the subhurd and it violates the original intention of creating subhurd.

Zheng Da




reply via email to

[Prev in Thread] Current Thread [Next in Thread]