sftp-server and chown

[Andy Polyakov]

> > I've already discussed this issue in SSHSCI's SSH 2.2 context on
> > ssh at clinet.fi list. My standpoint is that it's wrong and meaningless
> > to perform chown in sftp-server as the file is most likely copied
> > between systems with distinct accounting system where user is not
> > necessarily (and even unlikely) has same numeric user id.
> 
> If the sftp-client sends a request for CHOWN, why should I
> ignore it?

Because chown doesn't belong in file transer protocol and sftp should
not be an exclusion. As I said, numerical ids are very likely different
and chown is simply meaningless. Yes, they've specified it in protocol.
So what? They wanted to have the option opened, but it doesn't
autiomatically qualify it for implementation.

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

> > In addition
> > I think it's also irresponsible to blindly chmod files as different
> > systems might have different access policies (e.g. different umasks).
> > Therefore following patch (relative to OpenSSH 2.5.1p1) is suggested.
> 
> The sftp-server runs under the uid of the user, and the enviroment is
> setup by executing the login shell, so umask is set.

But umask doesn't prevent you from explicit chmod, does it? And that's
what happens, client asks for explicit chmod and umask is ineffective
then. Also note that explicit chmod can break file access/creation
policy controlled by ACLs... To tell you the truth I don't believe
absolute chmod belongs in file transfer protocol either. One should
probably limit it to incremental +x only (i.e. if you ask me:-).

Andy.