Mailing List Archive: [Bug 861] Swapped parameters of SSH_FXP

[Bug 861] Swapped parameters of SSH_FXP_SYMLINK packet of SFTP protocol

May 3, 2004, 11:35 PM

Post #1 of 3 (227 views)

http://bugzilla.mindrot.org/show_bug.cgi?id=861

Summary: Swapped parameters of SSH_FXP_SYMLINK packet of SFTP
protocol
Product: Portable OpenSSH
Version: -current
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: sftp-server
AssignedTo: openssh-bugs@mindrot.org
ReportedBy: opensshbugzilla@prikryl.cz

Hello,

I'm developer of WinSCP (SCP/SFTP client for Windows).
I have just realised that my client is probably sending parameters linkpath and
targetpath of SFTP SSH_FXP_SYMLINK packet in incorrect order. What has
surprised me is that despite this, it works fine with all OpenSSH SFTP servers.
Well otherwise I would have noticed earlier :-) This made me believe that
OpenSSH SFTP server has the same bug.
Ssh.com SFTP server obviously adheres to the standards, so with it my client
cannot create the links.

Can you confirm this?

http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt

The SSH_FXP_SYMLINK request will create a symbolic link on the
server. It is of the following format

uint32 id
string linkpath
string targetpath

The latest (CVS) sftp-server.c:

873: oldpath = get_string(NULL);
874: newpath = get_string(NULL);
875: TRACE("symlink id %u old %s new %s", id, oldpath, newpath);
876: /* this will fail if 'newpath' exists */
877: ret = symlink(oldpath, newpath);

The same bug is obviously even in OpenSSH SFTP client:
The latest (CVS) sftp-client.c:

647: id = conn->msg_id++;
648: buffer_put_char(&msg, SSH2_FXP_SYMLINK);
649: buffer_put_int(&msg, id);
650: buffer_put_cstring(&msg, oldpath);
651: buffer_put_cstring(&msg, newpath);

Have a nice day.

Martin Prikryl
http://www.prikryl.cz/
http://winscp.sourceforge.net/

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 861] Swapped parameters of SSH_FXP_SYMLINK packet of SFTP protocol [ In reply to ]

bugzilla-daemon at mindrot

May 11, 2004, 6:40 PM

Post #2 of 3 (230 views)

Permalink

http://bugzilla.mindrot.org/show_bug.cgi?id=861

dtucker@zip.com.au changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED

------- Additional Comments From dtucker@zip.com.au 2004-05-12 12:40 -------
Yep, that looks like a bug to me. I suspect the confusion is due to
SSH_FXP_SYMLINK having its arguments in the opposite order to the equivalent
Unix "ln" command, whereas other (eg FXP_RENAME) are the same as their equivalents.

The next question is what to do about it, and when? AFAIK, sftp doesn't know
what SSH server is on the other end, except for the SFTP protocol version (it
just runs "ssh -s host sftp"). Maybe fix it next time the protocol version
supported is bumped?

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 861] Swapped parameters of SSH_FXP_SYMLINK packet of SFTP protocol [ In reply to ]

bugzilla-daemon at mindrot

May 11, 2004, 11:52 PM

Post #3 of 3 (227 views)

Permalink

http://bugzilla.mindrot.org/show_bug.cgi?id=861

------- Additional Comments From opensshbugzilla@prikryl.cz 2004-05-12 17:52 -------
Are there any plans to support newer version of SFTP? You support version 3,
while there is version 5 draft published already.

BTW: version 5 has mechanism to detect version of SFTP server software (not
SFTP protocol version).

Possible (maybe dirty) workaround would be to utilize SFTP extension to let the
client know if the bug is fixed already. But it would not solve problem when
other vendors's client connects to your server.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.