Dear Damien,
Thanks for your review!
On Sun, Feb 6, 2022 at 11:37 PM Damien Miller <djm@xxxxxxxxxxx> wrote:
> 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.
>
The updated version of the patch (
https://github.com/openssh/openssh-portable/pull/299) looks like fixing
these issues:
I explicitly pass the flag allowing creating the directory only in case
when scp -r is in use.
> 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 agree, this is not feasible.
> I strongly recommend getting your employer to backport the existing
> sftp-server fixes (569b650f93b and 53a6ebf1445).
>
Sure, these fixes are worth backporting though deploying them may take a
long time.
--
Dmitry Belyavskiy
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
