lkml.org 
[lkml]   [2006]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (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/

\
 
 \ /
  Last update: 2006-02-16 19:01    [W:0.086 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site