Re: [PATCH 3 of 6] svcrpc: move export table checks to a per-program pg_add_client method

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Sep 24, 2004 at 02:04:16PM +1000, Neil Brown wrote:
> On Thursday September 23, bfields@fieldses.org wrote:
> > On Wed, Sep 22, 2004 at 04:54:12PM +1000, Neil Brown wrote:
> > > Alternately, the code which causes a call-back to be meaningful
> > > (e.g. nlmclnt_lock in lockd (??)) could insert the relevant
> > > information into the auth cache in advance.
> > 
> > There's not really a reliable way to do that with the current code since
> > userspace can flush the auth_domain cache at whim.
> 
> 
> Hmm... yes. Thanks.
> 
> I'm thinking that you really need to either involve user-space in
> authenticating callbacks (issues like multi-homed servers mean that
> the kernel cannot cope by itself at all)

I can't find anything definitive on this in any rfc, but I don't believe
that clients are required to be able to deal with callbacks from a
different IP address (or that a server should allow such a thing to
happen).  Can anyone find evidence to the contrary?

> or not require RPC authentication at all (the way 2.4 works).

I believe the ip-address checking done by the nfsv4 callback service and
by lockd are correct.

Over rpcsec_gss, nfsv4 callbacks also have to be authenticated (by
checking that the principal making the callback is the server's).

> Does anyone have objections to the following patch, which presumes the 
> svcauth_unix_set_client patch from Bruce.  With it, locking starts
> working again.

This patch would suffice if we're content to postpone authentication
until the dispatch or procedure-specific code.  If we do that, then we
end up returning an NFS or NLM error instead of having the call rejected
at the rpc layer.

So, do we require the ability to e.g return an rpc auth error on
authentication failure?

If not, then the cleaner solution would be to do the same thing for
nfsd--don't do any upcalls at accept() time, and move that stuff into,
say, nfsd_dispatch(), instead.

If we *do* need to allow programs to reject rpc calls at the rpc layer,
then we need something like the program-specific hook I propose (with
some modifications to make it flavor-independent, so it works for gss as
well).

--b.


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs