On Thu, 3 Feb 2022, Dmitry Belyavskiy wrote: > Dear Damien, > > Here is a proof-of-concept patch fixing this issue for me. If it could be > polished, it would be great. > diff --git a/sftp-client.c b/sftp-client.c > index c7565755..98f986d6 100644 > --- a/sftp-client.c > +++ b/sftp-client.c > @@ -1028,11 +1028,42 @@ do_realpath_expand(struct sftp_conn *conn, const char *path, int expand) ... > + if (status != SSH2_FX_NO_SUCH_FILE) { > + error("%s %s: %s", expand ? "expand" : "realpath", > + path, *errmsg == '\0' ? fx2txt(status) : errmsg); > + free(errmsg); > + sshbuf_free(msg); > + return NULL; > + } else { > + if((r = do_mkdir(conn, path, &a, 0)) != 0) { > + return NULL; > + } Sorry, but no way. This will attempt a directory creation any time a realpath operations fails. Any "cd" in the sftp client will have the chance to create a directory. scp without -r could create directories, etc. This server-side bug is difficult to fix in the client. Basically you'd need to reimplement realpath() on the client side using remote stat/readlink operations. It's possible, but not trivial, and a fair bit of compat code for us to carry around in perpetuity. I strongly recommend getting your employer to backport the existing sftp-server fixes (569b650f93b and 53a6ebf1445). -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev