Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755117AbZAFXgO (ORCPT ); Tue, 6 Jan 2009 18:36:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752104AbZAFXfz (ORCPT ); Tue, 6 Jan 2009 18:35:55 -0500 Received: from mail-out2.uio.no ([129.240.10.58]:34208 "EHLO mail-out2.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751844AbZAFXfy (ORCPT ); Tue, 6 Jan 2009 18:35:54 -0500 Subject: Re: [RFC][PATCH 2/4] sunrpc: Use utsnamespaces From: Trond Myklebust To: "J. Bruce Fields" Cc: "Eric W. Biederman" , "Serge E. Hallyn" , Matt Helsley , Linux Containers , linux-nfs@vger.kernel.org, Linux Kernel Mailing List , Chuck Lever , Linux Containers , Cedric Le Goater In-Reply-To: <20090106233238.GD13785@fieldses.org> References: <20090106011314.534653345@us.ibm.com> <20090106011314.961946803@us.ibm.com> <20090106200229.GA17031@us.ibm.com> <1231274682.20316.65.camel@heimdal.trondhjem.org> <20090106215831.GE18147@us.ibm.com> <1231283734.8041.6.camel@heimdal.trondhjem.org> <20090106233238.GD13785@fieldses.org> Content-Type: text/plain Date: Tue, 06 Jan 2009 18:35:43 -0500 Message-Id: <1231284943.8041.8.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3CC8CCF62218B8FEE8781D99A821A8A48B4D89B5 X-UiO-SPAM-Test: remote_host: 68.40.183.129 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 329 max/h 9 blacklist 0 greylist 0 ratelimit 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1242 Lines: 26 On Tue, 2009-01-06 at 18:32 -0500, J. Bruce Fields wrote: > On Tue, Jan 06, 2009 at 06:15:34PM -0500, Trond Myklebust wrote: > > On Tue, 2009-01-06 at 15:04 -0800, Eric W. Biederman wrote: > > > That implies to me you want to capture the value at mount time, and to > > > pass it in to the rpc_call creation, and only at very specific well > > > defined points where we interact with user space should we examine > > > current->utsname(). At which point there should be no question > > > of current->utsname() is valid as the user space process is alive. > > > > Why pretend that the filesystem is owned by a particular namespace? It > > can, and will be shared among many containers... > > If the only purpose of this is to fill in the auth_unix cred then > shouldn't it be part of whatever cred structures are passed around? So how does tracking it in a shared structure like the rpc_client help? If you consider it to be part of the cred, then it needs to be tracked in the cred... Trond -- 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/