From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: Simo Sorce <simo@redhat.com>,
"bfields@redhat.com" <bfields@redhat.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/4] Add support for new RPCSEC_GSS upcall mechanism for nfsd
Date: Tue, 10 Jul 2012 18:38:18 -0400 [thread overview]
Message-ID: <20120710223818.GA6720@fieldses.org> (raw)
In-Reply-To: <1341959112.17428.19.camel@lade.trondhjem.org>
On Tue, Jul 10, 2012 at 10:25:13PM +0000, Myklebust, Trond wrote:
> On Tue, 2012-07-10 at 18:12 -0400, Trond Myklebust wrote:
> > Then why is it being labelled as a knfsd-only change?
It should be labeled an rpc server change.
> > How will it behave if I don't run gss proxy?
It will work, but if the server's running on the same machine it will
also use svcgssd, and hence won't (for example) be able to handle the
larger init_sec_context packets.
> ...and how will it behave in a net namespace?
It will need the same fixes as we need for rpcbind.
I'm sure we could allow the callback server and the nfs server to use
different authentication upcalls. But that makes this not worth it.
We should be able to share the same use the same mechanism on all rpc
servers, so if a mechanism based on gssproxy calls isn't acceptable for
the nfs callback server then I'll drop it.
--b.
next prev parent reply other threads:[~2012-07-10 22:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 22:09 [PATCH 0/4] Add support for new RPCSEC_GSS upcall mechanism for nfsd Simo Sorce
2012-05-25 22:09 ` [PATCH 1/4] SUNRPC: conditionally return endtime from import_sec_context Simo Sorce
2012-05-25 22:09 ` [PATCH 2/4] SUNRPC: Document a bit RPCGSS handling in the NFS Server Simo Sorce
2012-05-25 22:09 ` [PATCH 3/4] SUNRPC: Add RPC based upcall mechanism for RPCGSS auth Simo Sorce
2012-05-25 22:09 ` [PATCH 4/4] SUNRPC: Use gssproxy upcall for nfsd's RPCGSS authentication Simo Sorce
2012-07-10 20:49 ` [PATCH 0/4] Add support for new RPCSEC_GSS upcall mechanism for nfsd J. Bruce Fields
2012-07-10 21:05 ` J. Bruce Fields
2012-07-12 12:39 ` J. Bruce Fields
2012-07-12 22:05 ` Simo Sorce
2012-07-12 22:42 ` J. Bruce Fields
2012-07-10 21:52 ` Myklebust, Trond
2012-07-10 21:56 ` J. Bruce Fields
2012-07-10 22:12 ` Myklebust, Trond
2012-07-10 22:25 ` Myklebust, Trond
2012-07-10 22:38 ` J. Bruce Fields [this message]
2012-07-10 22:58 ` Myklebust, Trond
2012-07-11 17:03 ` J. Bruce Fields
2012-07-11 17:27 ` J. Bruce Fields
2012-07-11 17:49 ` Myklebust, Trond
2012-07-12 22:10 ` J. Bruce Fields
2012-07-13 15:43 ` J. Bruce Fields
2012-08-08 19:36 ` J. Bruce Fields
2012-08-08 19:43 ` J. Bruce Fields
2012-08-08 20:12 ` Stanislav Kinsbursky
2012-08-21 14:16 ` J. Bruce Fields
2012-08-21 14:25 ` Myklebust, Trond
2012-08-21 14:29 ` J. Bruce Fields
2012-08-21 14:27 ` Stanislav Kinsbursky
2012-08-10 13:07 ` Stanislav Kinsbursky
2012-07-11 11:15 ` Simo Sorce
2012-07-13 15:45 ` J. Bruce Fields
2012-07-13 15:55 ` Simo Sorce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120710223818.GA6720@fieldses.org \
--to=bfields@fieldses.org \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=simo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.