Re: Stateless SFTP server and READDIR race condition.

[Michael Closson <closson%cs.ualberta.ca@localhost>]

On Thu, 2006-04-13 at 20:17 -0400, der Mouse wrote:
> > This is kind of a nit-pick, but I seems to me that the SFTP server
> > cannot be implemented as a stateless server because the server must
> > track the directory offset to support multiple READDIR calls.
> 
> I don't think you'd want to anyway, because the key exchange and
> authentication overhead would be insane.  Rememebr that SFTP is
> intended to be used as an SSH subsystem, and it's designed for that
> environment.  While it doesn't necessarily have to be done there, it
> does mean that its design tradeoffs are partially optimized for that
> environment.

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.

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.

> 
> > Also, there is a potential race condition when there are multiple
> > READDIR calls.
> 
> Could you detail this?  I don't see any race condition unless there are
> directory-modifying calls involved.

Yes, a third party could modify the directory on the server side.

The race condition comes down to this:  (I'm using the OpenSSH
implementation as a reference).

1. SFTP OPENDIR causes an opendir() on the server.
2. 1st SFTP READDIR causes 100 call to readdir().
3. Third party modifies directory on server in some arbitrary way.
4. 2nd SFTP READDIR causes at most 100 additional calls to readdir().
Entries could be missed.

So, I guess it comes down to the implementation of opendir()/readdir()
on the server.  Maybe it isn't a problem at all.


> 
> > Second, since SFTP returns multiple directory entries instead of one
> > (as is the case with NFS)
> 
> ...huh?  There's no inherent reason a single NFS READDIR can't return
> multiple directory entries.  A server that refuses to do so when there
> is space available I would be tempted to call defective, unless there
> is some unusual justification (such as its running on a microcontroller
> or some such).

Opps, looks like my recollection of the NFS protocol is a little hazy.
You are correct.  I guess the two protocols are similar in this aspect,
they each return multiple entries, but maybe not all of them (due to
packet size limitations, either an application layer limit or a
transport layer limit).



Mike Closson