Improving sftp (was Re: BUG: scp -r follows symlinks)

[Peter Stuge]

On Sun, Jan 11, 2004 at 06:37:57PM +1100, Damien Miller wrote:
> On Sun, 2004-01-11 at 17:22, Peter Stuge wrote:
> > > If there is something you want that it doesn't have,
> > > add it and send a patch!
> > 
> > Aye. After readline and completion it needs recursion[2] (is server push
> > possible?) and resume[3] which both seem to be not quite as far along..
> 
> I'm not sure what you mean by "server push", but it is probably not
> possible with the current sftp protocol, as all operations are initiated
> by the client.

Client says "give me tree rooted at /home/user/dir" and server complies.
Perhaps by using tar? :) (I.e. server recurses, instead of client.)


> Recursion would be nice, someone just needs to make a patch. This is
> probably the biggest thing holding sftp back from properly replacing
> sftp.

Using tar it would be trivial, but that isn't quite as smart as e.g. the
mirror command in lftp, which resumes what needs to be resumed in order
to synchronize the directory. Works upstream with -R too.


> > When that's done, I think anonymous access and bandwidth and transfer
> > count limits is "all" that's needed for sftp to take the place of most
> > FTP installations. (..that I know about, at least. :)
> 
> Anonymous access isn't the responsability of sftp, but it is easy enough
> to set up anyway.

True!


> > Also, what would be the best way to only allow users access to a certain
> > subsystem and not the shell or command execution, and how to go about
> > creating virtual users that should just be mapped onto some real UID?
> 
> Custom shell.

Right, setuid (wrapper), switches to appropriate user after checking it
should actually allow this particular thing to happen. Pretty much what
rssh does if I'm not mistaken.

I was aiming for replying with SSH_MSG_CHANNEL_FAILURE to any disallowed
SSH_MSG_CHANNEL_REQUEST even before executing anything, instead of having
the custom shell just exit after deciding it shouldn't run, but I think I
just missed the intention of the replies - "If the request is not
recognized or is not supported for the channel, ..FAILURE is returned."

This implies that the connection protocol shouldn't bother with checking
what's allowed and not.. I guess the logic to accomplish such control is
considered to cost more (in lines of code) than it's worth (in CPU time)
too?


> > I assume no, they shouldn't be broken out. How does everyone feel
> > about the features I mention above? I'm not sure an ssh implementation
> > should include all of that code..
> 
> We have no plans for bandwidth of transfer limits (i'm not sure they
> belong there), but everything else is already planned.

Awesome. :) I thought about the bandwidth limit for a minute and it seems
like a good idea to have that in sftp-server since I doubt it's possible to
set ToS to limit bandwidth in a portable manner, whereas it's easy for
sftp-server to "just wait" now and then when sending. I agree it would be
better to put the control elsewhere, but I'm not sure it's very doable?
Transfer limits would be done in the custom shell.

It would be very nice to keep all sftp configuration in one place, i.e.
the custom shell.


> The extra code doesn't bloat sshd, sftp-server is a separate binary
> and process. Ditto the client.

True separate programs, but still part of OpenSSH. Of course you're right
that sshd is the critical component though.

Thanks for the input and discussion!


//Peter