[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1231287607.11487.0.camel@heimdal.trondhjem.org>
Date: Tue, 06 Jan 2009 19:20:07 -0500
From: Trond Myklebust <Trond.Myklebust@...app.com>
To: "J. Bruce Fields" <bfields@...ldses.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
"Serge E. Hallyn" <serue@...ibm.com>,
Matt Helsley <matthltc@...ibm.com>,
Linux Containers <containers@...ts.linux-foundation.org>,
linux-nfs@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Chuck Lever <chuck.lever@...cle.com>,
Linux Containers <containers@...ts.osdl.org>,
Cedric Le Goater <clg@...ibm.com>
Subject: Re: [RFC][PATCH 2/4] sunrpc: Use utsnamespaces
On Tue, 2009-01-06 at 18:35 -0500, Trond Myklebust wrote:
> 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...
OK. If people really want to track this, then you could add a reference
to the current->nsproxy to the struct rpc_cred and struct auth_cred, and
ensure that the unx_marshal and unx_match routines do the right thing
w.r.t. that reference (if it exists).
However such a patch had better be accompanied with a _really_
convincing argument for why containers need this...
As for the NFSv4 clientid, I can't see how you would ever want to use
anything other than the init->utsname(), since the requirement is only
that the clientid string be unique and preserved across reboots. The
server isn't allowed to interpret the contents of the clientid string.
Ditto for the RPCSEC_GSS machine creds that are used to establish the
clientid.
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@...app.com
www.netapp.com
--
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