Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757911AbZAGBK1 (ORCPT ); Tue, 6 Jan 2009 20:10:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756219AbZAGBKO (ORCPT ); Tue, 6 Jan 2009 20:10:14 -0500 Received: from mx2.netapp.com ([216.240.18.37]:58315 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755763AbZAGBKM (ORCPT ); Tue, 6 Jan 2009 20:10:12 -0500 X-IronPort-AV: E=Sophos;i="4.37,222,1231142400"; d="scan'208";a="108990493" Subject: Re: [RFC][PATCH 2/4] sunrpc: Use utsnamespaces From: Trond Myklebust To: Matt Helsley Cc: "Serge E. Hallyn" , Linux Containers , linux-nfs@vger.kernel.org, Linux Kernel Mailing List , "J. Bruce Fields" , Chuck Lever , "Eric W. Biederman" , Linux Containers , Cedric Le Goater In-Reply-To: <1231288999.14345.231.camel@localhost> 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> <1231281732.4173.6.camel@heimdal.trondhjem.org> <1231286930.14345.196.camel@localhost> <1231287619.11487.2.camel@heimdal.trondhjem.org> <1231288999.14345.231.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: NetApp Date: Tue, 06 Jan 2009 20:10:02 -0500 Message-Id: <1231290602.11487.42.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 X-OriginalArrivalTime: 07 Jan 2009 01:10:10.0497 (UTC) FILETIME=[AFC89B10:01C97064] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2103 Lines: 48 On Tue, 2009-01-06 at 16:43 -0800, Matt Helsley wrote: > On Tue, 2009-01-06 at 19:20 -0500, Trond Myklebust wrote: > > On Tue, 2009-01-06 at 16:08 -0800, Matt Helsley wrote: > > > IMHO This seems more incorrect than trying to use a more proximal > > > namespace. > > > > You have yet to explain why. > > It's "more proximal" -- it's closer to the container that we expect to > cause (directly or otherwise) the bulk of the RPC calls for that mount. > If the container does not wind up sharing that mount with other > containers then the reported node name matches. If the container winds > up sharing the mount with other containers then at least we can learn > which container originated the mount. > > I imagine an NFS administrator trying to determine the source of a bunch > of RPC calls. If we just report the initial namespace then that > administrator has to do lots more digging to determine which container > sent the calls (assuming they aren't in different network namespaces). As I said elsewhere, the network namespaces do not matter, since we always create the sockets via the rpciod workqueue. > By not always reporting the initial namespace we may give the > administrator one way to narrow down the search. Even if the reported > node name does not perfectly match the source of all RPC traffic related > to the mount at least the administrator gets something more specific. The administrator would have to be running wireshark or something in order to track the rpc calls. That's hardly a convenient interface, or a compelling reason to add namespace info into RPC credentials. We certainly haven't added any other information to the RPC calls in order to allow the administrator to identify which process it originated from. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com -- 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/