Re: Stateless SFTP server and READDIR race condition.

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Tue, Apr 18, 2006 at 11:37:33AM -0600, Michael Closson wrote:
> Yes, you are correct.  I guess that stateless doesn't necessarily mean
> reconnect on every request.  Although ssh connection sharing (openssh)
> could be used.  I guess the question becomes, why would one ever want to
> implement a stateless server?  I don't know.

Statelessness has got to mean that you can recover from having to
reconnect (e.g., because the server or the client rebooted or what have
you [in NFSv4 because of network partitions that lasted longer than time
periods associated with leases]).

> I made this comment because in the current sftp draft section 8.1 second
> paragraph it states that sftp open/close allows for the implementation
> to be either stateful or stateless.  open/close may allow this, but
> readdir doesn't, so there is a small inconsistency with the spec.

I don't believe what you say about readdir.  If a client's connection is
reset in the middle of a readdir the client can reconnect and continue,
possibly by redoing the readdir completely and comparing to what it had
read up to the point where the connection was dropped.

In all cases if the protocol lacks any support for file leases and/or
directory change notifications then clients may see slightly different
file/directory contents.

When we talk about stateless filesystem protocols we mean server-side
statelessness, not client-side statelessness.  I've not combed through
it recently, but, at the very least version 3 of SFTP is indeed
stateless, to the best of my recollection.

Nico
--