This appears on OpenSSH under AIX, but I think it may also impact Linux: /home/kallies/topdir/subdir> chmod 770 targetdir /home/kallies/topdir/subdir> cd .. /home/kallies/topdir> chmod 110 subdir /home/kallies/topdir> cd .. /home/kallies> chmod 110 topdir /home/kallies> ls topdir ls: topdir: The file access permissions do not allow the specified action. /home/kallies> ls topdir/subdir ls: topdir/subdir: The file access permissions do not allow the specified action. /home/kallies> echo "this is my data" > topdir/subdir/targetdir/datafile.txt /home/kallies> ls topdir/subdir/targetdir datafile.txt /home/kallies> cat topdir/subdir/targetdir/datafile.txt this is my data Under FTP, the directories behave as you would expect: 230 User kallies logged in. ftp> cd topdir 250 CWD command successful. ftp> ls 200 PORT command successful. 550 No files found. ftp> cd subdir 250 CWD command successful. ftp> ls 200 PORT command successful. 550 No files found. ftp> cd targetdir 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening data connection for .. datafile.txt myfile.txt 226 Transfer complete. ftp> However under SFTP, it does not: sftp> ls topdi* topdir/ sftp> ls topdir Couldn't get handle: Permission denied sftp> ls topdir/subdir Couldn't get handle: Permission denied sftp> ls topdir/subdir/targetdir topdir/subdir/targetdir/. topdir/subdir/targetdir/.. topdir/subdir/targetdir/datafile.txt sftp> cd topdir/subdir/targetdir Couldn't canonicalise: No error sftp> get topdir/subdir/targetdir/datafile.txt myfile.txt datafile.txt 100% 16 8.4KB/s 00:00 sftp> This breaks GUI utilities (e.g. WinSCP), and isn't quite like FTP behaviour.
Bugzilla newbie here, smack me if I'm breaking etiquitte. Reassigning to the owner of the selected component (sftp-server)
Yes, this problem is known (it is actually in the client) but is a little tricky to fix. Basically the sftp client does a realpath() to verify that a path is accessible and to change relative paths into absolute ones, but realpath breaks on traverse only directories. The solution is to modify the client to fall back to doing a stat() on the path when the realpath() fails. The client can then just continue, using a relative path. This isn't particularly nice either, because it adds another round-trip for each "cd" command (only on realpath error though)
That's makes sense, so realpath() breaks in sftp-server because sftp-server is running as the user, whereas FTP servers are not quite so diligent about security?
Not quite: most ftp server can actually do a chdir() to set the current working directory. The sftp protocol doesn't even have the concept of a "current working directory", so our implementation uses realpath() to convert between the paths that the user types (which may be relative) and absolute filesystem paths. This conversion isn't 100% necessary, and it may be possible to skip it in some cases - e.g. when realpath() fails
Hello, I'm author of the metioned SFTP client (WinSCP). I have been just experimenting with this issue. For me realpath does succeed on OpenSSH server on Linux (shell.sourceforge.net). With OpenSSH client (sftp) I'm able to enter the traverse-only directory. Of course I'm not able to list its content. With my client (WinSCP) and PSFTP (Putty package) I'm not able to enter it. The reason it that both clients attempt to read the directory content (just open/close, no reading actually) in addition to doing "realpath" on it to make sure it actually exists. I do not know why Putty authors does this. I'm doing it because on some servers (for example OpenSSH on cygwin) "realpath" succeeds even for non-existing directories. I guess I'll do "stat" instead of reading the directory. So I believe you may close this bug, as there is no problem neither with OpenSSH client nor server.
As per your feedback, I'm tagging this as resolved-invalid. Thank you very much to everyone for having a look at this. Will the new versions of PSFTP and WinSCP contain the code change you described? Thanks again,
Actually, this is still a known problem for the OpenSSH sftp client. You can't "cd", but you can still do get/put/ls operations on the full path (see below). The fix is as I described in comment #2, but I haven't implemented it yet. [djm@baragon djm]$ cd /tmp [djm@baragon tmp]$ mkdir -p dir_1/dir_2/dir_3 [djm@baragon tmp]$ chmod 0755 dir_1 dir_1/dir_2/dir_3 [djm@baragon tmp]$ chmod 111 dir_1/dir_2 [djm@baragon tmp]$ sftp -S /usr/libexec/sftp-server blah Connecting to blah... sftp> pwd Remote working directory: /tmp sftp> cd dir_1/dir_2/dir_3 Couldn't canonicalise: Permission denied sftp> pwd Remote working directory: /tmp sftp> ls dir_1/dir_2/dir_3 sftp> put /bin/ls dir_1/dir_2/dir_3/foo Uploading /bin/ls to /tmp/dir_1/dir_2/dir_3/foo /bin/ls 100% 175KB 175.4KB/s 00:00 sftp> get /tmp/dir_1/dir_2/dir_3/foo /tmp/blah Fetching /tmp/dir_1/dir_2/dir_3/foo to /tmp/blah /tmp/dir_1/dir_2/dir_3/foo 100% 175KB 175.4KB/s 00:00 sftp> ls -l dir_1/dir_2/dir_3 -r-xr-xr-x 1 djm wheel 179648 Jan 12 16:25 foo sftp>
I'm not sure when this got fixed, but it works now: [djm@djm openssh]$ cd /tmp [djm@djm tmp]$ mkdir -p dir_1/dir_2/dir_3 [djm@djm tmp]$ chmod 0755 dir_1 dir_1/dir_2/dir_3 [djm@djm tmp]$ chmod 111 dir_1/dir_2 [djm@djm tmp]$ sftp -D /usr/lib/openssh/sftp-server Attached to /usr/lib/openssh/sftp-server. sftp> cd dir_1/dir_2/dir_3 sftp> put /bin/ls ls Uploading /bin/ls to /tmp/dir_1/dir_2/dir_3/ls /bin/ls 100% 136KB 162.6MB/s 00:00 sftp> ^D [djm@djm tmp]$ ls -l dir_1/dir_2/dir_3 total 136 -rwxr-x--- 1 djm primarygroup 138856 Jul 31 14:58 ls
closing resolved bugs as of 8.6p1 release