bug-hurd
[Top][All Lists]
Advanced

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

a design flaw when associating a user to a process?


From: Da Zheng
Subject: a design flaw when associating a user to a process?
Date: Tue, 13 Jan 2009 00:12:13 +0000
User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

olafBuddenhagen@gmx.net wrote:
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.

Are you saying that if a task fails to register itself with the proc
server, it can not be associated with any user, i.e. only root can kill
the task? That would be a serious security problem for all I know...
As far as I see, yes.
The processes in subhurd doesn't belong to the user who runs the subhurd in the eyes of the main Hurd. Therefore, the user has to trust subhurd and supposes it can kill all processes in subhurd when subhurd is closed. if the subhurd fails to boot, the normal user might have no way to close it.

In my understanding, a process inherits the user information from its parent, and it has to call auth_makeauth() explicitly to create a new auth port. Later, it calls proc_reauthenticate(), and the process server can get the user information of the process. However, neither of them can happen to the processes in subhurd. The process server in subhurd can only be aware of the tasks in subhurd when it calls processor_set_tasks() in add_tasks(), but it has no way to get the user information.

First, I'm not sure whether we should fix the problem. It surely isn't good that the tasks created by the user cannot be closed.

If we do need to fix it, I think we need the help of the kernel. It seems that mach doesn't track the children of a task, so I am thinking how about sending the notification (it shows which task is created from the parent task) to the task who requests it when a new task is created (it's very much like mach_port_request_notification). When the process server can get the notification, it can associate the new task to the parent task's user.
This mechanism can also help boot track the tasks in subhurd.

Could anyone give me some comments?
Thank you

Zheng Da





reply via email to

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