OpenSSH GSoC Project

[Damien Miller]

On Wed, 25 Mar 2009, Salvador Fandino wrote:

> > > - remove the max packet size limitation for read and write operations
> > > that forces SFTP clients to send/get data in chunks. File data could be
> > > moved directly between the network (actually from the slave SSH process
> > > pipes) and the on disk file without going to a memory buffer first.
> > 
> > I suspect that would break the current RFC draft.  Thus would either an official 
> > way to detecting, or an unofficial hack, your talking to an older server.
>
> The draft requires the server to accept at least 32KB packets, but it
> doesn't limit the maximum size in any way. An entry on the INIT reply
> could be used to tell the client the maximum packet size.

Why bother? With the current packet size the overhead is something like
30KB per GB of data transferred, but increasing this makes the protocol
perform worse for multiple concurrent operations (which we admittedly 
underutilise now) and less responsive to early aborts, etc.

> > > - implement an extension to allow rsync over SFTP (ssync :-)
> > > 
> > > - implement fine grained access control for the SFTP server, limiting
> > > which SFTP operations are available (for instance, forbidding directory
> > > reading).
> >
> > The file permissions should be access control. Having yet another
> > layer on top of it is silly. The only valid argument ftp has for
> > doing such garbage is they support an "anonymous" mode where it
> > isn't a real user.
>
> That's like saying that firewalls are useless because access control
> can be performed at the service level
>
> Being able to stablish policies from a central point would be a real
> advantage.

We have ChrootDirectory that can be used to limit sftp access to subtrees
of the file system. Perhaps sftp-server could benefit from a read-only
mode, but I think that too many access control options just lead to
confusion.

> I am not proposing to replace sftp-server with a Perl script, I am just
> saying that it wold be interesting to have an implementation in a high
> level language to allow others to extend it in any way they want:
> access control, loging, generating content on the fly, triggers,
> whatever...

Something like this might be useful to improve testing of both the
client and server. The sftp protocol is so simple that it would be
quite easy to write.

-d