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: olafBuddenhagen
Subject: Re: looking for the solution of rootless subhurd
Date: Thu, 15 Jan 2009 12:03:15 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Sat, Jan 10, 2009 at 08:29:02PM +0000, Da Zheng wrote:

> I just found that there are two RPCs that can change the kernel ports
> of  tasks and threads: thread_set_kernel_port and
> task_set_kernel_port. Mach does provide an easy way to override these
> two ports:-)

That's great news :-)

I saw these RPCs when reading through the Mach documentation, but
somehow totally failed to realize that the kernel port set there is
actually the port returned by mach_task_self()/mach_thread_self()...

> I will explore how to get the subhurd tasks from the process server of
> main Hurd first.

I wonder whether this is the preferable route. It seems that we will
have to intercept the task/thread kernel ports in the subhurd anyways,
to prevent set_priority() failing. And if we intercept them anyways, we
could just as well also track task creation in the subhurd...

So maybe it is better to explore this possibility first -- especially as
it doesn't seem to require fixing fundamental design issues, which would
seriously delay further progress...

Of course the other route is interesting nevertheless: The problem with
obtaining the task's owner is a generic one, not really limited to
subhurd -- IMHO it should be fixed in any case.

Also, in some use cases it should be acceptable to demand that the
system running in the subhurd can cope with set_priority() failing --
100% transparency is not always required... So I guess it could be made
an option. In this case, it would be nice if we could get away without
intercepting kernel ports.

> I know the current task is to make subhurd run by all users, but I am
> thinking that maybe we can create a completely isolated subhurd
> (including the resource isolation).

Indeed, while the primary goal is running subhurd as normal user, it is
evidently a desirable variation to have a completely isolated subhurd.
This is precisely why I suggested to make it an option whether the
subhurd should see the user's other tasks, or only the subhurd tasks.

-antrik-




reply via email to

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