Re: looking for the solution of rootless subhurd

[olafBuddenhagen]

Hi,

On Thu, Jan 01, 2009 at 09:11:16PM +0000, Zheng Da wrote:
> On Mon, Dec 22, 2008 at 10:04 AM, <olafBuddenhagen@gmx.net> wrote:

> > 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.

Which is always the case for rootless subhurd, so we should be fine :-)

> > > One way I think of is to use a different RPC. Suppose it is called
> > > mach_task_to_subhurd_task(mach_port_t subhurd_port, task_t task).
> > > Therefore, the task in subhurd gets its task port with
> > > mach_task_self()  and translate it to subhurd task port with this
> > > RPC.
> >
> > Well, if we really need to modify the client-side code for obtaining
> > the task port, I guess a simpler and more efficient approch would be
> > to inject a send right for the pseudo task port into the process
> > address space at process creation time, and simply read that when
> > mach_task_self() is attempted. (Pseudo thread port is more tricky,
> > though.)
> 
> I doubt it can work. We can inject the send right to the process when
> we create it, but the problem is how the process know the name of the
> port (the name of port, I mean, is the integer value).

The right could be inserted under a fixed name (as already happens with
some ports AIUI), or the name could be stored at a known place in the
new process's address space, like the environment is...

But again, we should try to avoid client-side changes alltogether, if
possible. This is only a fallback solution; we do not need to consider
it for now.

> It might already be out of topic because we don't need to deal with it
> if the possible solution I found above works.

Which solution do you mean?

-antrik-