sftp: cant download files when chroot directory is a symlink

[jjverschoor]

"OpenSSH for Windows" version
8.0.0.0.0

Server OperatingSystem
Windows Server 2012 R2 Datacenter

Client OperatingSystem
windows 10 (1803)

What is failing
can browse directory structure but cant download files when using symlink as chroot directory.

Expected output
to be able to download files via sftp

Actual output
access denied.

=====================================================
We came across similar sftp symptoms as in issue/1403 (Copying files by sftp to junction not possible under Windows 10 when ChrootDirectory is set in sshd_config)
in that..

• we could browse the directory structure and retrieve folder listing, but
• we could not download files with error: permission denied,

..when using a /D symlink as chrootdirectory (whilst if we dont use a chrootdirectory and navigate to the symlink manually we can indeed download the files from the referred directory, so NTFS is all ok).

this is different from 1403 as 1403 referenced outside of chroot, which we didn't.... Rather our chroot is a symlink, and we stay within the chroot.

Is this something that the code can be updated for, i.e. to allow for file download when chrootdirectory is a /D symlink? or am I doing something wrong?

Info:

• windows server 2012R2
• OpenSSH v8.0.0.0 installed in C:\program files\OpenSSH
• sshd_config:

PermitEmptyPasswords no
AuthenticationMethods password
ForceCommand internal-sftp
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
ChrootDirectory C:\the-/D-sym-link
Subsystem sftp internal-sftp

Server log:
debug3: auth2_update_methods_lists: updating methods list after "password" [preauth]
debug2: authentication methods list 0 complete [preauth]
debug3: send packet: type 52 [preauth]
debug3: mm_request_send entering: type 26 [preauth]
debug3: mm_send_keystate: Finished sending state [preauth]
debug3: ReadFileEx() ERROR:109, io:000000CFDD89E110
debug3: read - no more data, io:000000CFDD89E110
debug1: monitor_read_log: child log fd closed

Client log (winscp)
2019-10-22 10:49:41.029 Handling network read event on socket 1536 with error 0
2019-10-22 10:49:41.029 Received 38 bytes (0)
2019-10-22 10:49:41.029 Read 4 bytes (34 pending)
2019-10-22 10:49:41.029 Read 34 bytes (0 pending)
2019-10-22 10:49:41.030 Type: SSH_FXP_STATUS, Size: 34, Number: 21251
2019-10-22 10:49:41.030 65,00,00,53,03,00,00,00,03,00,00,00,11,50,65,72,6D,69,73,73,69,6F,6E,20,64,
2019-10-22 10:49:41.030 65,6E,69,65,64,00,00,00,00,
2019-10-22 10:49:41.030 Status code: 3, Message: 21251, Server: Permission denied, Language:
2019-10-22 10:49:41.030 (ETerminal) Permission denied.
2019-10-22 10:49:41.030 Error code: 3
2019-10-22 10:49:41.030 Error message from server: Permission denied
2019-10-22 10:49:41.030 Asking user:
2019-10-22 10:49:41.030 Cannot open remote file '/xxx/xx/x/xxx.txt'. ("Permission denied.
2019-10-22 10:49:41.030 Error code: 3
2019-10-22 10:49:41.030 Error message from server: Permission denied")
2019-10-22 10:49:41.114 Session upkeep

[jjverschoor]

Just as an update: version 8.1.0.0 exhibits the same behaviour.

[jjverschoor]

Update2:

Looks like the logic to support a symlink as a chroot directory is not built into the code it yet.
So, for now, we just commented out the file chroot checks in the "file_in_chroot_jail"-function in "fileio.c" that our symlink failed, as per below:

(version 8.1.0.0. lines 419 till 438 in "fileio.c")

/* returns 1 if true, 0 otherwise /
int
file_in_chroot_jail(HANDLE handle) {
/ ensure final path is within chroot */
wchar_t *final_path;

final_path = get_final_path_by_handle(handle);
if (!final_path)
	return 0;

to_wlower_case(final_path);
if ((wcslen(final_path) < wcslen(chroot_pathw)) /*||
	memcmp(final_path, chroot_pathw, 2 * wcslen(chroot_pathw)) != 0 ||
	final_path[wcslen(chroot_pathw)] != '\\'*/) {
	debug3("access denied due to attempt to escape chroot jail");
	return 0;
}

return 1;

}

This bypasses the file chroot checks, and we just rely on chdir chroot checks to prevent sftp users from clicking themselves out of the chroot directory. (We use NTFS for access control, so for now we can get away with it, but if the developers could build in the logic to support symlink as chroot, that would be great).

PS. please don't copy the above, as part of the code is garbled by the text editor.

[bagajjal]

@jjverschoor - Please try the attached private sftp-server binary.
sftp-server-v8.9-UNCsymlink-chroot.zip

[maertendMSFT]

This fix will be included in our 9.X release

[365iT-Solutions]

any update on this ?