sftp-server and chown

[mouring at etoh.eviladmin.org]

On Wed, 21 Feb 2001, Andy Polyakov wrote:

> > > > sftp-server is running with the uid/privileges of the user, so why
> > > > care?
> > >
> > > As I already said, some systems *permit* chown to another uid even for
> > > non-priviledged users (and most systems can be configured by changing a
> > > kernel parameter to permit this operation and some do configure it so)
> > > and this is one-way operation, i.e. once I did 'chown markus file' I
> > > can't chown it back to myself.
> > 
> > well, so why should i ignore chown if it's legal on some
> > systems?
> 
> Because it breaks things in a manner no normal user would expect it to
> break during a trivial file transfer. Here is system call trace for
> SSHCSI's SSH 2.2.x (Windows client and server):
> 
> unlink("/my/dir/a.txt")                         = 0
> open("/my/dir/a.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
> fchmod(3, 0)                                    = 0
> fchown(3, 0, 0)                                 = 0
> fchmod(3, 0100666)                              Err#1 EPERM
> utime("/my/dir/a.txt", 0xEFFFF94C)              Err#1 EPEPM
> fchmod(3, 0100666)                              Err#1 EPERM
> utime("/my/dir/a.txt", 0xEFFFF94C)              Err#1 EPERM
> 
> User gets ---------- file owned by root and the only thing [s]he can do
> is delete the damn thing. I realize that it might no be 100% applicable
> to OpenSSH (I didn't check if it does chmod(0) to mark
> "transfer-in-progress"), but the point is that when you transfer a file
> you expect to own it on the target system no matter what and therefore
> the idea of chown (in any file transer server) is inherently tainted.
> 
> On the other hand even if you logged on with sftp as root, why whould
> you like to grant ownership to whomever on the target system who simply
> happened to have same numeric id as file owner on the source system?
> 
> Andy.
> 

I have a lot of quarms with how ssh.com designed their sftp client in
windows.  It's broken and horrible.  And I don't feel we should remove a
feature because a company can't figure out how to write a correct sftp
client.  Catering to broken software is never a valid solution.

I would love to see sftp expanded.  I'd love to see a remote 'MOVE'
command implemented.  I'm tired of all theses 'file transfer' 
programs/protocols that ignore the fact that people don't care about
'moving' files any more, but the fact that they want to 'manage' files
between multiple machines.  And downloading 50 megs of files just to
upload them into a new directory is not a valid solution IMHO.