sftp-server and chown

[Andy Polyakov]

> > > 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.