Messages in this thread | | | Date | Thu, 24 Nov 2011 00:14:36 +0400 | From | Pavel Emelyanov <> | Subject | Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids |
| |
On 11/23/2011 10:19 PM, Pavel Emelyanov wrote: > On 11/23/2011 08:24 PM, Tejun Heo wrote: >> Hello, >> >> On Wed, Nov 23, 2011 at 04:20:44PM +0000, Pedro Alves wrote: >>>> Would CAP_CHECKPOINT be a shame too? >>> >>> I think CAP_CHECKPOINT (or something through some LSM) would be >>> definitely better. >>> >>>> I'm reluctant about priviledge >>>> through fd inheritance mostly because of its unusualness. I don't >>>> think priv management is a good problem space for small creative >>>> solutions. We're much better off with mundane mechanisms which people >>>> are already familiar with and is easy to account for. >>> >>> fd inheritance wouldn't work for gdb; a user spawned gdb >>> wouldn't inherit an open fd to kernel.ns_last_pid from anywhere. >> >> I see. So, let's do it for root for now and later add finer grained >> CAP as necessary/viable. Pavel, what do you think? > > OK, I'll send the respective patches soon.
Hm... Started testing this stuff and thought about Pedro's wish to use this in gdb one more time :(
The thing is, that we (in checkpoint/restore) are going to use this sysctl when creating a pid namespace from scratch, thus having full control over all the forks happening in this namespace.
But when it comes to the ability for gdb to create a task with a given pid in a _living_ namespace this solution simply won't work! It doesn't guarantee, that after setting the last_pid via sysctl this last_pid stays the same at the time we do call fork()/clone(). Because there are other tasks that can call fork themselves ignoring any lask_pid locking we can play with.
That said I see only two real-life scenarios of how to use _this_ API:
1. creating tasks in a new pid namespace, making sure all the fork-ers care about the proper locking; 2. forking tasks in a loop checking that getpid() returns desired value and hoping that other tasks do not fork() at speed high enough for spoiling every single last_pid value set via sysctl.
Is any of these scenarios suitable for Pedro? Other thoughts on this?
>> Thanks. >> >
| |