Hi, On Tue, Jan 13, 2009 at 12:12:13AM +0000, Da Zheng wrote: > olafbuddenha...@gmx.net wrote:
>> 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. Ouch... > 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. I see. > First, I'm not sure whether we should fix the problem. Yes, I think we should definitely try to fix it. As I said, I think this is a very fundamental problem -- subhurd is only one manifestation... > 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, Maybe changing that would be the easiest approach?... I guess it shouldn't be too hard to add a notion of parent task to Mach. > 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. Yeah, I was thinking along these lines as well. Instead of a special purpose notification, proc might also just intercept the task kernel ports... Would be a relatively heavy-weight solution, but that might not be a serious problem in practice -- and it wouldn't require any kernel changes. Note that all of these solutions assume the new task is created directly by the parent process... I'm not sure whether this is indeed the case with the standard fork() and exec() mechanisms. (Especially for suid exec.) BTW, I think this is the sort of things we should definitely try to discuss with Roland and/or Thomas... -antrik-