Description of problem: When I mount FTP share with curlftpfs, it behaves differently based on SSL and debug options used. Mount of FTP always succeeds, but access to mount point fails on some occasions. If no SSL is used, access works. If -o ssl_control is used, access works only if also -o debug option is specified ( curlftpfs runs in foreground ), otherwise it fails. If -o ssl is used, access always fails, regardless of debug setting. Error returned by access to mount point ( for example by ls command ) is: ls: reading directory ftp: Input/output error Version-Release number of selected component (if applicable): RPMs: curlftpfs-0.9.2-17.fc21.x86_64 curl-7.37.0-12.fc21.x86_64 openssl-1.0.1k-1.fc21.x86_64 fuse-2.9.3-4.fc21.x86_64 # curlftpfs -V curlftpfs 0.9.2 libcurl/7.37.0 fuse/2.9 # curl -V curl 7.37.0 (x86_64-redhat-linux-gnu) libcurl/7.37.0 NSS/3.17.3 Basic ECC zlib/1.2.8 libidn/1.28 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz Metalink # fusermount -V fusermount version: 2.9.3 # openssl version OpenSSL 1.0.1k-fips 8 Jan 2015 How reproducible: Steps to Reproduce: 1. curlftpfs -o ssl,debug,uid=1000,gid=1000,user=myuser ftp://ftp.example.net:21/ ./ftp 2. ls ./ftp Actual results: ls: reading directory ftp: Input/output error Expected results: ftp directory contents Additional info: Fedora 21 Workstation Installation
Created attachment 981253 [details] curlftpfs debug log without SSL usage which worked
Created attachment 981254 [details] curlftpfs debug log with ssl_control usage which worked only with debug option
Created attachment 981255 [details] curlftpfs debug log with ssl usage which did not work
Thank you for your bugreport and willing make free software better! Does it reproduced with all FTP services of just with single? Could you provide test account (may be private) for reproducing?
Occurs also in Fedora 22 Workstation. # rpm -q curlftpfs curl fuse openssl curlftpfs-0.9.2-17.fc22.x86_64 curl-7.40.0-3.fc22.x86_64 fuse-2.9.3-4.fc22.x86_64 openssl-1.0.1k-8.fc22.x86_64 # curlftpfs -V curlftpfs 0.9.2 libcurl/7.40.0 fuse/2.9 # curl -V curl 7.40.0 (x86_64-redhat-linux-gnu) libcurl/7.40.0 NSS/3.18 Basic ECC zlib/1.2.8 libidn/1.29 libssh2/1.5.0 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets Metalink # fusermount -V fusermount version: 2.9.3 # openssl version OpenSSL 1.0.1k-fips 8 Jan 2015
I just tested with different server and that one was working, so this seem related to one service only. Following 2 examples show working and non-working mount with temporary test account: Does not connect: curlftpfs -o no_verify_peer,ssl,uid=1000,gid=1000,user=rhelbug118340.pessoft.com:rhelbug11834020160708 ftp://ftp.pessoft.com:21/ ./ftp Connects successfully: curlftpfs -o no_verify_peer,ssl_control,uid=1000,gid=1000,user=rhelbug118340.pessoft.com:rhelbug11834020160708 ftp://ftp.pessoft.com:21/ ./ftp
I'm experiencing the exact same issue using a RHEL 6.4 host I'm also observing a segfault being generated when attempting to access the directory: curlftpfs[6880]: segfault at 0 ip 000000300b067974 sp 00007f492a7a9050 error 4 in libc-2.12.so[300b000000+18a000] When that happens, i get this error: # cd /app/ftpext -bash: cd: /app/ftpext: Transport endpoint is not connected Otherwise i'm getting the same errot # ls -al /app/ftpext ls: reading directory .: Input/output error total 0 $ curlftpfs -V curlftpfs 0.9.2 libcurl/7.19.7 fuse/2.8 $ openssl version OpenSSL 0.9.8w-fips 23 Apr 2012 $ fusermount -V fusermount version: 2.8.3 $ curl -V curl 7.15.3 (x86_64-unknown-linux-gnu) libcurl/7.15.3 OpenSSL/0.9.8w Protocols: tftp ftp telnet dict ldap http file https ftps Features: GSS-Negotiate Largefile NTLM SSL Connecting with the -f option or disabling ssl works just fine. Let me know if you need additional information
Problem what I can't reproduce it. Is it reproduced on some open FTP server?
Can you test with server mentioned in Comment 6 (https://bugzilla.redhat.com/show_bug.cgi?id=1183409#c6) or provide some open FTP server?
As I can see there incorrect SSL certificate on that host: $ lftp -u rhelbug118340.pessoft.com,***** ftp.pessoft.com:21 lftp rhelbug118340.pessoft.com.com:~> ls ls: Fatal error: Certificate verification: certificate common name doesn't match requested host name ‘ftp.pessoft.com’ curlftpfs said something similar in first case: * Doing the SSL/TLS handshake on the data stream * warning: ignoring value of ssl.verifyhost * skipping SSL peer certificate verification * ALPN/NPN, server did not agree to a protocol * SSL connection using TLS_DHE_RSA_WITH_AES_128_CBC_SHA * Server certificate: * subject: CN=*.pipni.cz,OU=Domain Control Validated - RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)15,OU=GT13534967 * start date: Feb 08 10:14:36 2015 GMT * expire date: Mar 12 12:21:18 2017 GMT * common name: *.pipni.cz * issuer: CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US * Remembering we are in dir "" < 425 Unable to build data connection: Operation not permitted * server did not report OK, got 425 * Connection #0 to host ftp.pessoft.com left intact ftpfs: operation ftpfs_getattr failed because No such file or directory unique: 3, error: -2 (No such file or directory), outsize: 16 Could you connect and list directory content with this credentials in some other client?
I've tried in Midnight Command FTP connection and FileZilla. Both worked ( in FZ after accepting certificate ). However you are right about SSL issue. For valid SSL connection use following host instead: www17.pipni.cz:21 ( it is the same server ). I've tested this host with lftp connection and it worked as well.
The problem is with NSS (Red Hat's library of choice for crypto), whose functions now fail if it was initialized in the parent process: https://bugzilla.mozilla.org/show_bug.cgi?id=331096 That's exactly what's happening here. As the actual fork happens somewhere in FUSE, ensuring that curl_global_init(CURL_GLOBAL_SSL) is only called after isn't all that trivial. Thankfully someone implemented a workaround after the last comment in the linked bug report: NSS_STRICT_NOFORK=DISABLED restores the old behaviour and solves the problem for me.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This was still an issue in Fedora 26. Since Fedora 27 when curl changed from NSS to SSL, curlftpfs works as expected.