A few NFS reply-cache questions, and possible answers. Any feedback
would be appreciated.
1) Is a reply-cache needed over a reliable transport (TCP)?
Yes. Possible for a client not to receive a response due to a
disconnect. When re-connects, will retry the operation. Need to trap
this.
2) Cache look-up before checking for a client's export entry?
The reply-cache look-up/resource-allocation occurs from
nfsd_dispatch() - before the exp_get() check in fh_verify(). This
allows for an attacker to fill the reply-cache with 'bogus' entries,
reducing it usefulness. As NFS servers are either accessible only on
an intranet, or behind a firewall (unlikely?), this is not a serious
problem.
Partial fix is in nfsd_cache_lookup(), after checking 'type', test
if rq_client is NULL. Not ideal, but will catch most cases.
Full fix is to move call to nfsd_cache_lookup() into fh_verify()
(and anywhere else needed(?)) after the exp_get_fsid()/exp_get().
If this is consider an issue, shout and I'll do a patch.
3) For non-idempotent operations, hold an "inprogress-entry" in the
reply-cache?
This would really only be for read operations, and possibly getattr,
over an unreliable transport (UDP). On a 'busy' server, response
times may vary considerably; by trapping retransmitted requests which
are in-progress, the 'busy' server will not be further overloaded.
Note: I have no data to back this case up! Does anyone have some
hard-data/references on this?
Ideally, the 'inprogress' entry would be dropped _after_ the
response has been sent. With the current design, nfsd_dispatch() calls
nfsd_cache_update() before returning to the RPC code for a call to
svc_send(). A callback hook after svc_send() would be useful....
Thanks,
Mark
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Saturday August 9, [email protected] wrote:
> A few NFS reply-cache questions, and possible answers. Any feedback
> would be appreciated.
>
> 1) Is a reply-cache needed over a reliable transport (TCP)?
> Yes. Possible for a client not to receive a response due to a
> disconnect. When re-connects, will retry the operation. Need to trap
> this.
Yes, technically it is needed, though practically it probably isn't of
any use.
When the client re-connects it will almost certainly use a different
port number, so the cache will treat it as a different source of
requests and will never find a re-transmitted request.
>
> 2) Cache look-up before checking for a client's export entry?
> The reply-cache look-up/resource-allocation occurs from
> nfsd_dispatch() - before the exp_get() check in fh_verify(). This
> allows for an attacker to fill the reply-cache with 'bogus' entries,
> reducing it usefulness. As NFS servers are either accessible only on
> an intranet, or behind a firewall (unlikely?), this is not a serious
> problem.
> Partial fix is in nfsd_cache_lookup(), after checking 'type', test
> if rq_client is NULL. Not ideal, but will catch most cases.
> Full fix is to move call to nfsd_cache_lookup() into fh_verify()
> (and anywhere else needed(?)) after the exp_get_fsid()/exp_get().
> If this is consider an issue, shout and I'll do a patch.
Probably the simplest thing to do is to not cache replies that return
STALE. Any request from an unknown client will return ESTALE, and
there is no point caching that anyway (it is an idempotent reply).
>
> 3) For non-idempotent operations, hold an "inprogress-entry" in the
> reply-cache?
> This would really only be for read operations, and possibly getattr,
> over an unreliable transport (UDP). On a 'busy' server, response
> times may vary considerably; by trapping retransmitted requests which
> are in-progress, the 'busy' server will not be further overloaded.
> Note: I have no data to back this case up! Does anyone have some
> hard-data/references on this?
> Ideally, the 'inprogress' entry would be dropped _after_ the
> response has been sent. With the current design, nfsd_dispatch() calls
> nfsd_cache_update() before returning to the RPC code for a call to
> svc_send(). A callback hook after svc_send() would be useful....
>
Doest "RC_INPROG" work for you as an inprogress-entry? If so, it is
already implemented.
But read operations and getaddr are idempotent, not non-idempotent, so
either you or I are a bit confused.
NeilBrown
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 11 Aug 2003, Neil Brown wrote:
>
> > 3) For non-idempotent operations, hold an "inprogress-entry" in the
> > reply-cache?
> >
> Doest "RC_INPROG" work for you as an inprogress-entry? If so, it is
> already implemented.
Yes, "RC_INPROG" works as an inprogress-entry.
> But read operations and getaddr are idempotent, not non-idempotent, so
> either you or I are a bit confused.
It is me that is confused....
Mark
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs