This is a tougher variant of the previous question bad ownership or modes for chroot directory component.
In that other question, we learn that openssh refuses to chroot a user to its own home directory, if that home directory has the normal permissions. Instead you have to make root the owner of the user's home directory. This prevents the user from uploading to its own home directory.
I'm working with a program I'll call stupid_legacy_application
or SLA
for short, which wants to send me its output via sftp upload. And it insists on uploading to (what appears to the client to be) the root directory. The upload fails and leaves these messages in the server log:
Jun 17 18:05:53 sftphost sftp-server[29031]: open "/SLA\\SLA_Data_ 2018617_18551.zip" flags WRITE,CREATE,TRUNCATE mode 0666
Jun 17 18:05:53 sftphost sftp-server[29031]: sent status Permission denied
Note the mix of slash and backslashes in the path. I guess it was meant to talk to some Windows sftp server, and /SLA
is supposed to be a directory.
If I don't chroot the user, it tries to upload to the real root directory and fails. If I chroot the user and don't chown the directory to root, sshd doesn't allow the login. If I chroot the user and chown the directory to root, it fails again. If I add write permission for the user via group or world bits, sshd doesn't allow the login.
I even tried to fool it with an ACL, thinking that sshd wouldn't notice anything outside the traditional permissions, but I was only fooling myself (see this question for why that doesn't work).
Recompiling sshd with the directory permission check hacked out looks like the only way to fix this problem. Is there any other way? It doesn't need to be clean, since I only need this to work once, and the server is a disposable VM.