[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 30 Jun 2011 17:57:18 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Serge Hallyn <serge.hallyn@...onical.com>
Cc: akpm@...ux-foundation.org, mm-commits@...r.kernel.org,
daniel.lezcano@...e.fr, ebiederm@...ssion.com, mingo@...e.hu,
oleg@...hat.com, rdunlap@...otime.net, tj@...nel.org,
kernel-hardening@...ts.openwall.com
Subject: Re: + ipc-introduce-shm_rmid_forced-sysctl.patch added to -mm tree
Hi Serge,
On Thu, Jun 30, 2011 at 08:48 -0500, Serge Hallyn wrote:
> Quoting akpm@...ux-foundation.org (akpm@...ux-foundation.org):
> > +static int shm_try_destroy_orphaned(int id, void *p, void *data)
> > +{
> > + struct ipc_namespace *ns = data;
> > + struct shmid_kernel *shp = shm_lock(ns, id);
> > + struct task_struct *task;
> > +
> > + if (IS_ERR(shp))
> > + return 0;
> > +
> > + /*
> > + * We want to destroy segments without users and with already
> > + * exit'ed originating process.
> > + *
> > + * XXX: the originating process may exist in another pid namespace.
> > + */
>
> (Sorry, I no longer have the original patch. I'd meant to take a closer
> look at the time...)
>
> So shp should store a reference to the struct pid, which you can check
> here? I think that'll do exactly what you need.
Documentation/namespaces/compatibility-list.txt says that IPC and PID
namespaces have not been fully separated yet. This is a core problem.
If I store a reference to pid namespace, it would solve only this little
problem, but the global problem of pid vs. ipc namespaces is left
unsolved. It would be much more consistent to fix the whole ipc code in
one step (if ever).
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
