On Fri, 2007-11-02 at 01:04 -0700, Andrew Morton wrote:
> > > That is the "fix" you were referring to? I was hoping you have a sketch
> > > for a real solution. If nobody can think of a way to fix this PID
> >
> > Looks like we misunderstood each other. Can you please elaborate on
> > what exactly is broken in pid namespaces?
>
> Isn't it this?
>
> http://lkml.org/lkml/2007/11/1/141
I think we're still a bit murky on exactly what the issues are. Ingo,
Ulrich, is this the right track? The kind of issues that you're
concerned about?
There are certainly more of these, but here is one In the futex
userspace address, we install the current pid's vnr into a userspace
address.
static int futex_lock_pi(u32 __user *uaddr, struct rw_semaphore *fshared,
int detect, ktime_t *time, int trylock)
{
...
newval = task_pid_vnr(current);
curval = cmpxchg_futex_value_locked(uaddr, 0, newval);
We obviously don't have any restrictions on who else might be mapping
that address, so that pid can theoretically leak out to any other task.
In another pid namespace, the pid at that userspace address is certainly
nonsensical.
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
