linux-kernel - Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ECD542C.7010705@parallels.com>
Date:	Thu, 24 Nov 2011 00:14:36 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Tejun Heo <tj@...nel.org>, Pedro Alves <pedro@...esourcery.com>,
	Oleg Nesterov <oleg@...hat.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	James Bottomley <jbottomley@...allels.com>
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.
>>
> 

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