secsh-filexfer: any limit on the number of filehandles?

[Martin Pool <mbp%samba.org@localhost>]

I have been reading the current draft-ietf-secsh-filexfer-04.txt.  It
looks like a very nicely designed protocol.

   Many operations in the protocol operate on open files.  The
   SSH_FXP_OPEN request can return a file handle (which is an opaque
   variable-length string) which may be used to access the file later
   (e.g.  in a read operation).  The client MUST NOT send requests the
   server with bogus or closed handles.  However, the server MUST
   perform adequate checks on the handle in order to avoid security
   risks due to fabricated handles.

I am a little concerned that there is no discussion of a limit on the
number of open files.  

In a situation where the user is not completely trusted by the server
this could pose some kind of resource exhaustion problem, either by
using up file descriptors, kernel file handles, or just entries in a
table of handles.  Consider for example a customer uploading files to
a shared web host over sftp, or an anonymous/readonly server over TCP.

The server could of course impose a limit on the number of files that
any client is allowed to open at a time.  In itself that kind of
implementation decision doesn't need to be discussed here.  

It is not clear to me what error a server ought to return in that
situation.  Perhaps SSH_FX_INVALID_HANDLE?  It might be nice if this
were specified, so that a client could potentially close off another
handle and try again.  Possibly a new error should be defined?

I do think requiring clients to close files is probably easier than
the NFSv4 system of the server invalidating handles and requiring the
client to reacquire them.

The standard perhaps should mention what expectations a client can
have about keeping handles open.  For example, it might say that a
client must be able to handle a server which only allows a single file
to be open at a time, or perhaps it should say that a server SHOULD
allow at least (say) eight handles to be open.

I don't know what limit would make sense for existing implementations
but I do think the question should be addressed.

-- 
Martin