Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SFTP path "/~" is no longer resolving #11001

Closed
speculzzz opened this issue Apr 18, 2023 · 3 comments
Closed

SFTP path "/~" is no longer resolving #11001

speculzzz opened this issue Apr 18, 2023 · 3 comments

Comments

@speculzzz
Copy link

I tried to access the home directory via SFTP and received an error, even though this type of request was working before:

$ curl -u builder 'sftp://192.168.236.1/~'
Enter host password for user 'builder':
curl: (78) Could not open remote file for reading: SFTP server: No such file

About my Ubuntu 22.04:

$ curl -V
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

$ uname -a
Linux user-Latitude-5520 6.2.10-1-liquorix-amd64 #1 ZEN SMP PREEMPT_DYNAMIC liquorix 6.2-13ubuntu1~jammy (2023-04 x86_64 x86_64 x86_64 GNU/Linux

This behavior appeared after adding commit 4e2b52b5f7a3bf50a.

After investigating the issue, I found out the following:

  1. The new algorithm only resolves the path /~/, but /~ remains unchanged.
  2. I added support for /~, but after successful resolving to /home/builder, the resulting request still didn't work
$ ./src/curl -u builder 'sftp://192.168.236.1/~'
Enter host password for user 'builder':
curl: (56) Failure when receiving data from the peer

It turned out that for SFTP requests, it's necessary to finalize the path with a /. In the old algorithm, when resolving ~, symbol / was automatically added after the home directory in the resulting path, which allowed the request to work. But, for example, the next request didn't work:

$ curl -u builder 'sftp://192.168.236.1/home/builder'
Enter host password for user 'builder':
curl: (56) Failure when receiving data from the peer

So I'm not sure yet whether the function Curl_getworkingpath() should resolve the path /~ to /home/user or to /home/user/ , as it was before.

@bagder
Copy link
Member

bagder commented Apr 18, 2023

It did strike me that we generally document that you need to end the path with a trailing slash to get a directory listing, which this does not. So, I'm not sure if we need to fix the code or make the documentation clearer...

@speculzzz
Copy link
Author

So, if I understand you correctly, in the previous version (before commit 4e2b52b5f7a3bf50a), it was mistakenly possible to successfully process the request sftp://url/~, but now this has been fixed and it is necessary to write sftp://url/~/?

bagder added a commit that referenced this issue Apr 25, 2023
libcurl used to do a directory listing for this case (even though the
documentation says a URL needs to end in a slash for this), but
4e2b52b modified the behavior.

This change brings back a directory listing for SFTP paths that are
specified exactly as /~ in the URL.

Reported-by: Pavel Mayorov
Fixes #11001
@bagder
Copy link
Member

bagder commented Apr 25, 2023

I made #11023 that brings back the previous behavior

@bagder bagder closed this as completed in 91b53ef Apr 26, 2023
bch pushed a commit to bch/curl that referenced this issue Jul 19, 2023
libcurl used to do a directory listing for this case (even though the
documentation says a URL needs to end in a slash for this), but
4e2b52b modified the behavior.

This change brings back a directory listing for SFTP paths that are
specified exactly as /~ in the URL.

Reported-by: Pavel Mayorov
Fixes curl#11001
Closes curl#11023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants