SSH2/SFTP newline breaks path causes segfault and "Save Changes" missing in UI

[thajekku]

Trying to use the SSH2 update method on 4.1. Running on Red Hat Enterprise Linux 6.6 with php55 and httpd24 from SCL (software collections).

After installing the php55-php-pecl-ssh2 I was getting segfaults from php-fpm causing "Service Unavailable" messages when performing certain functions such as trying to remove a plugin (installing a plugin however worked).
I also noticed that I did not have the "Save Changes" submit button in Settings->General or anything underneath TimeZone. TimeZone was simply showing "UTC+0".

I worked through Red Hat support to rule out php-fpm as the cause and it appears that there is a newline being introduced in the pwd call in class-wp-filesystem-ssh2.php causing the issue.
It makes the path /var/www/sites/wca/ turn into /var/www/sites/wca\n/.
Part of the trace is below:

        #0  __strlen_sse42 () at ../sysdeps/x86_64/multiarch/strlen-sse4.S:32
        #1  0x000000000058d4bf in _estrdup (s=0x0) at /usr/src/debug/php-5.5.6/Zend/zend_alloc.c:2630
        #2  0x00007fcb122aac76 in php_ssh2_fopen_wraper_parse_path (path=0x36ab5c8 "ssh2.sftp://Resource id #140/var/www/sites/wca\n/", type=<value optimized out>, context=0x0, psession=0x7fffe8cab9d0,
            presource_id=0x7fffe8cab9dc, psftp=0x7fffe8cab9c8, psftp_rsrcid=0x7fffe8cab9d8) at /usr/src/debug/php55-php-pecl-ssh2-0.12/NTS/ssh2_fopen_wrappers.c:226
        #3  0x00007fcb122ad626 in php_ssh2_sftp_urlstat (wrapper=<value optimized out>, url=<value optimized out>, flags=2, ssb=0x7fffe8cabad0, context=<value optimized out>)
            at /usr/src/debug/php55-php-pecl-ssh2-0.12/NTS/ssh2_sftp.c:390
        #4  0x000000000056a65f in _php_stream_stat_path (path=0x36ab5c8 "ssh2.sftp://Resource id #140/var/www/sites/wca\n/", flags=2, ssb=0x7fffe8cabad0, context=0x0)
            at /usr/src/debug/php-5.5.6/main/streams/streams.c:1933
        #5  0x0000000000507a82 in php_stat (filename=0x36ab5c8 "ssh2.sftp://Resource id #140/var/www/sites/wca\n/", filename_length=<value optimized out>, type=12, return_value=0x3a657f8)
            at /usr/src/debug/php-5.5.6/ext/standard/filestat.c:906

It appears that a simple fix might be to just rtrim the call to pwd in class-wp-filesystem-ssh2.php, at least that fixed the issues I am seeing (do not know if it introduces any).

I changed the following function (just line 187) from:

186         public function cwd() {
187                 $cwd = $this->run_command('pwd');
188                 if ( $cwd )
189                         $cwd = trailingslashit($cwd);
190                 return $cwd;
191         }

to

186         public function cwd() {
187                 $cwd = rtrim($this->run_command('pwd'));
188                 if ( $cwd )
189                         $cwd = trailingslashit($cwd);
190                 return $cwd;
191         }

After making that change it appears that the SSH2 functions work properly.

[thajekku]

Reference for what the General Settings Looks like with this issue.

[hippothamus]

YMMV with ​https://wordpress.org/support/plugin/ssh-sftp-updater-support

[thajekku]

Thanks for the link, I am aware of the ssh-sftp plugin and appreciate the work that was put into it and the options it gives those of us that use the SSH2 update mechanism.
My first instinct though was to start with the SSH/SFTP support in WordPress Core as it has always worked for me in the past (assuming I had php-pecl-ssh2 installed ) and came across this bug.
Just thought if the functionality remains in core ( and is not removed in preference of the plugin as has been argued at #16925 ) then it should work properly and any bugs should be reported here.
thanks again.

[dd32]

This sounds like a strange and interesting bug, and i have absolutely no issues in trimming the paths here.

The question that is on my mind though, is should this trimming be done within run_command() and only strip a suffixed \r & \n characters from the string? I struggle to see why any newline characters need to remain.

[crimson090]

Thank you very much for this. I spent 3 hours investigating an issue where we could not delete a plugin without nginx returning a 404 error (interesting installing and updating worked fine). This was the solution.

[ocean90]

Duplicate of #30802.