[PATCH] nfsd: pass client principal name in rsc downcall

[J. Bruce Fields]

On Tue, Jan 15, 2008 at 06:41:04PM -0500, Trond Myklebust wrote:
> 
> On Tue, 2008-01-15 at 17:54 -0500, J. Bruce Fields wrote:
> > On Tue, Jan 15, 2008 at 05:47:31PM -0500, Trond Myklebust wrote:
> > > This is information that describes the context that rpc.gssd is to
> > > create. It belongs in the upcall, and _only_ there. We should not have
> > > 50 different ways of talking to rpc.gssd.
> > 
> > Do you also intend the destination address, port, server name, etc., to
> > move into the upcall eventually?  That's all also used in creating those
> > contexts.
> > 
> > I don't have particularly strong feelings about it either way.  But it
> > seems cleaner (and perhaps slightly more efficient) to put information
> > that is really per-operation into the upcall, and information that's
> > constant into something like "info".
> 
> It isn't at all cleaner. It is an ad-hoc band-aid for the one and only
> case where you don't have more than a single user of the rpc_client.

Sorry, there still seems to be a misunderstanding.  This isn't the
principal that the calls will be authenticated *as*.  This is the
principal that the calls will authenticate *to*.  That principal is
always the same, for all rpc clients.  This isn't a special case in that
respect.

(In fact, I suppose it's possible there might be some use for this even
for regular nfs rpc client, if we wanted to allow people to run
experimental servers as principals other than nfs at hostname.  While
nfs at hostname is what the rfc says the server MUST identify itself as, it
could be that the same reasons that make it occasionally useful to run
nfs on a non-standard port could also apply to running it as a
non-standard principal.)

--b.

> 
> > > It doesn't matter if we're going to use the resulting cred only once, or
> > > if we're going to use it for every operation that passes through the
> > > rpc_client, we're _not_ inventing special interfaces for this.
> > 
> > Why not?  What's the disadvantage?
> 
>       * It provides yet another entirely separate userland interface
>         that needs to be maintained forever.
>       * There are no users of this interface aside from the nfsv4.0
>         server callbacks. Not even nfsv4.1 can use it.
>       * It does nothing to solve the existing upcall specification
>         problems outside nfsv4.0's limited bailiwick.
> 
> If we do need to review the existing kernel/rpc.gssd interface, then
> _the_ top requirement should be that the new interface must address all
> the new functionality needs that we know we have today. No ad-hoc hacks.
> 
> For instance, it should at least fix the problem that we have with
> specifying machine cred vs real cred. IMO we should also be looking into
> integrating what we need for the keyring-based upcalls too.