Messages in this thread | | | Date | Thu, 16 Feb 2006 11:57:49 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: (pspace,pid) vs true pid virtualization |
| |
Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > > > Quoting Herbert Poetzl (herbert@13thfloor.at): > >> > - Should a process have some sort of global (on the machine identifier)? > >> > >> this is mandatory, as it is required to kill any process > >> from the host (admin) context, without entering the pid > >> space (which would lead to all kind of security issues) > > > > Just to be clear: you think there should be cases where pspace x can > > kill processes in pspace y, but can't enter it? > > > > I'm not convinced that grounded in reasonable assumptions... > > Actually I think it is. The admin should control what is running > on their box.
Of course. I meant "grounded in reasonable security assumptions."
If you really are the admin then you will find another way of "getting into" the pspace.
But really, what does "enter" mean in this case? If you can see the processes so as to kill them, is that all you need? After all this is distinct from the filesystem namespace - the pids are the only thing that's distinct. So the only thing that I can see you preventing by preventing "entering" the pspace is starting a new process with a pid valid in the other pspace.
-serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |