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