Error when putting file with permissions while ChrootDirectory is set

[argonym]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

When I put -p somefile while the connected user has a ChrootDirectory set, the operation always fails with "remote fsetstat: Bad message".

The probable root cause was tracked down by @MichaelEischer. Quoting from restic/restic#4335 (comment):

The error looks very much like a bug in the homegrown chroot implementation used in the Windows openssh sftp port. In https://github.com/PowerShell/openssh-portable/blob/661803c9ec4d7dee6574eb6ff0c85b2b7006edb1/contrib/win32/win32compat/w32fd.c#L1013 it first retrieves the filepath for the handle (the real path on the windows filesystem) and passes it to w32_chmod which applies the chroot a second time!
That ultimately results in a call to _wchmod with a broken file path. This triggers an EINVAL error that gets translated to the "Bad message" error.

Expected behavior

sftp> put -p somefile
Uploading somefile to /somefile
somefile                                      100%   22KB   6.9MB/s   00:00
<transfer completes w/o error>

Actual behavior

sftp> put -p somefile
Uploading somefile to /somefile
somefile                                      100%   22KB   6.9MB/s   00:00
remote fsetstat: Bad message

Error details

No response

Environment data

AllowGroups ssh-backup
Match Group ssh-backup
	AuthorizedKeysFile C:/_backups/%u.authorized_keys
	ChrootDirectory C:/_backups/%u

Version

OpenSSH_for_Windows_9.4p1, LibreSSL 3.7.3

Visuals

No response

[argonym]

Hi @tgauth or @maertendMSFT, I'd appreciate if you find the time to look into this issue.
The bug is easily reproducible and probably also fixable with little changes.

[FriisParisi]

Thanks @argonym for posting about this issue.

We experienced the exact same symptom with OpenSSH 9.5.0.0 on Windows Server 2022 with a VMware NSX backup apparently writing using the -p param.

The post helped us determine that setting the ChrootDirectory property does in fact cause this issue for us.
To workaround the issue we temporarily disabled the ChrootDirectory configuration and instead made use of a directory symbolic link from C: to D:\data on the destination server to target the D: drive that way.

Monitoring this issue, hoping for a permanent solution