Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753607AbbBYAlO (ORCPT ); Tue, 24 Feb 2015 19:41:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40351 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752290AbbBYAlN (ORCPT ); Tue, 24 Feb 2015 19:41:13 -0500 Date: Tue, 24 Feb 2015 16:41:04 -0800 (PST) From: Benjamin Coddington X-X-Sender: bcodding@planck.local To: "J. Bruce Fields" cc: Ian Kent , "Eric W. Biederman" , David Howells , Kernel Mailing List , Oleg Nesterov , Trond Myklebust , Al Viro , Jeff Layton Subject: Re: [RFC PATCH 5/8] KEYS: exec request-key within the requesting task's init namespace In-Reply-To: <20150224153329.GA2415@fieldses.org> Message-ID: References: <1424306341.2649.12.camel@pluto.fritz.box> <20150219013116.GA13131@fieldses.org> <1424424805.2632.24.camel@pluto.fritz.box> <20150220172558.GD18103@fieldses.org> <877fvc319o.fsf@x220.int.ebiederm.org> <20150220190547.GE18103@fieldses.org> <1424491138.2641.83.camel@pluto.fritz.box> <20150223145237.GB21246@fieldses.org> <1424739027.2616.20.camel@pluto.fritz.box> <20150224153329.GA2415@fieldses.org> User-Agent: Alpine 2.19.9992 (OSX 65 2014-06-20) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2292 Lines: 46 On Tue, 24 Feb 2015, J. Bruce Fields wrote: > On Mon, Feb 23, 2015 at 05:22:12PM -0800, Benjamin Coddington wrote: > > That sounds a lot closer to some of the work I've been doing to see if I can > > come up with a way to solve the "where's the namespace I need?" problem. > > > > I agree with Greg's very early comments that the easiest way to determine > > which namespace context a process should use is to keep it as a copy of > > the task -- and the place that copy should be done is fork(). > > So you're suggesting that the key_agent could be that copy? But: > > > ... If not, then the calling process itself is forked/execve-ed into a > > new persistent key_agent that is installed on the calling process' > > keyrings just like a key, and with the same lifetime and GC > > expectations of a key. > > > > A key_agent is a user-space process... > > If the key_agent can die before it's needed, then we have to keep around > some other context information to allow regenerating a new one. So what > is that piece of information? Aren't we back where we started? Yes. It would seem to make sense then to keep a copy of task which would be used to create the user-space key_agent. If that's the standard behavior, it doubles the number of tasks for the average use case. The average use case (I anticipate) would be to just always fork the caller if a key_agent is not found. It would probably make sense provide the key_agent_type the option of binding a key_agent reference task to another structure -- like a mount. And, if so, that reservied reference task would be used to create/re-create the user-space key_agent. The trouble there is how to have the caller communicate the object bound to the task.. a reference to the object could be guessed, which would give any caller access to a that reserved task.. In order to keep further verbose speculation to a minimum, I'll say: good point.. there may be a way to authorize the usage of a reference task by means of the possession of an authkey. I'll keep hacking at this. Ben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/