Re: A future for the SSH File Transfer Protocol?

[Simon Tatham <anakin%pobox.com@localhost>]

Darren Moffat  <Darren.Moffat%eng.sun.com@localhost> wrote:
> I'd like to suggest that before the group goes any further with SFTP we
> stop and do a requirements spec.  
> 
> What problem are we really trying to solve for the end user ?
> 
> In particular is the goal a file transfer protocol along the lines of
> FTP (as the name would suggest) or is it a file sharing protocol more
> in line with NFS or CIFS.

As I see SFTP, its purpose is to allow a useful level of file system
access, in a platform-independent manner, _making use of SSH
authentication_.

In NFS:

 - you have a single centralised NFS arrangement between the
   administrators of a pair of machines, and each user gets to make
   use of that same arrangement.

 - the admins negotiate a uid mapping, finding something clever to
   do about uids that aren't matched on the other machine.
   Alternatively, they arrange to have matching uids everywhere.

 - each side trusts the other not to abuse that uid mapping; if the
   client were to make a mistake in enforcement, one of its users
   might be able to write to a file they aren't supposed to be
   allowed to. So the server is extending its trust perimeter to
   include the client's kernel.

Whereas in SFTP:

 - each user who wants filesystem access authenticates separately,
   so there isn't a need for the admins to cooperate.

 - uid mapping can be done, if the user feels it would be helpful,
   but it is informational only, because the real guarantee of the
   access control being respected on the server is that the
   sftp-server process doesn't _have_ the privileges to access files
   it shouldn't.

 - So if a uid mapping is wrong, there is no security breach. The
   client user gets confusing information, but it's only the
   _information_ that is faulty. Access control is still intact.

 - Hence, the server does not need to trust the client to enforce
   the access controls: it enforces them itself.

All of this is the case _irrespective_ of whether it's being used as
a networked file system or an FTP-like file transfer client; the
interface presented to the client user is irrelevant. (Although I
suppose uid mapping is a bit irrelevant in the latter case :-)

Interestingly, of course, one major area of user interfaces for SFTP
clients is the Windows Explorer-like drag-and-drop interface - which
precisely _does_ blur the user-level distinction between a dedicated
file transfer client and a networked file system!

> Why doesn't running the FTP protocol over SSH transport help,

FTP lacks several _very_ nice features of SFTP:

 - the ability to retrieve only part of a file (REST is helpful in
   some situations but doesn't really cut it)

 - a properly specified, reliably available chmod and chgrp (and I
   suppose chown, for people mad enough to do it as root :-)

 - directory listings returned in a machine-readable form

 - of course, the well-known chaos with multiple network connections

In general, it would be very difficult to write a specialised client
that would use FTP to perform a specific and complex file
manipulation on a remote server. But SFTP makes this easy (not least
because it has access to SSH's hands-off authentication), and
therefore it's a qualitative improvement over FTP. (Shame about
ASCII transfer, of course, but it's an extensible protocol so that
can be fixed...)

In summary: I see SFTP as being an excellent middle way between NFS
and FTP. It's not sysadmin-heavy like NFS, and yet it's way more
flexible and more automatable than FTP. The basic structure of the
protocol is _exactly_ what I would want to see in a file transfer
_or_ filesystem access protocol, and it's highly extensible so its
current lack of polish can be seamlessly fixed.

Cheers,
Simon
-- 
Simon Tatham         "A cynic is a person who smells flowers and
<anakin%pobox.com@localhost>    immediately looks around for a coffin."