Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with givenpids

[Pavel Emelyanov]

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.
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/