[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ECD3946.1030503@parallels.com>
Date: Wed, 23 Nov 2011 22:19:50 +0400
From: Pavel Emelyanov <xemul@...allels.com>
To: Tejun Heo <tj@...nel.org>
CC: Pedro Alves <pedro@...esourcery.com>,
Oleg Nesterov <oleg@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Alan Cox <alan@...ux.intel.com>,
Roland McGrath <roland@...k.frob.com>,
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 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.
> 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/
Powered by blists - more mailing lists