On Mon, Dec 22, 2008 at 10:04 AM,
<olafBuddenhagen@gmx.net> 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 believe it can cause a serious security problem if the subhurd can
> see all tasks in the host and every user can create his own subhurd.
> If a subhurd can see a task, it means it can also destroy the task.
> As a result, any user (suppose the user have the root permission in a
> subhurd) can destroy any tasks in the host.
Not at all. The subhurd's processes, from the main Hurd's point of view,
all run with the rights of the user who started the subhurd. They do not
have permission to manipulate other users' processes.
Depending on some details of the implementation which I don't know, it
could be possible to manipulate processes belonging to the user who
started the subhurd, from within the subhurd. Depending on the
individual use case, that might or might not be desirable...
I'm more and more convinced that filtering tasks visible in the subhurd
should be made an option.
I think we talk about different things. I am talking about the task and you are talking about the process. The concept of the process is created by Hurd. However, the task is the thing in Mach's point of view.
I say that someone can see the task, that is, he can get the port to access the task. That means that he can destroy the task with task_terminate(). I think that's why the proc server has to strictly control the access to the task port and pid2task can only work for the tasks that belong to the caller.
Again, my point is that subhurd shouldn't get the ports of all tasks.
> 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).
It might already be out of topic because we don't need to deal with it if the possible solution I found above works.
Zheng Da