SSL problems after locally scoped disconnect
Closed this issue · 8 comments
See the note at the end of this report first...
DBD::mysql version
5.003, 5.004, 5.005
MySQL client version
8.0.37
Server version
8.4.0
Operating system version
Linux (amazonlinux:2), libssl.so.1.0.2k
What happened?
Creating a connection using DBD::mysql
versions 5.003 - 5.005 in a locally scoped block and then disconnecting in the same locally scope block puts SSL in a state where downstream SSL connections fail with a 500 (internal response).
The script below will demonstrate the problem:
use strict;
use warnings;
use LWP::UserAgent;
use Net::SSLeay;
use HTTP::Request;
use Data::Dumper;
use DBI;
$Net::SSLeay::trace = 2;
my $dsn = sprintf 'dbi:mysql:%s:%s', $ENV{DBI_DBNAME}, $ENV{DBI_HOST};
my $dbi = DBI->connect( $dsn, $ENV{DBI_USER}, $ENV{DBI_PASS} );
my $req = HTTP::Request->new( GET => 'https://google.com' );
my $ua = LWP::UserAgent->new;
my $rsp = $ua->request($req);
print {*STDERR} Dumper( [ status => $rsp->status_line ] );
connect_and_do_something($dsn);
$rsp = $ua->request($req);
print {*STDERR} Dumper( [ status => $rsp->status_line ] );
########################################################################
sub connect_and_do_something {
########################################################################
my ($dsn) = shift;
my $dbi = DBI->connect( $dsn, $ENV{DBI_USER}, $ENV{DBI_PASS} );
$dbi->disconnect;
}
1;
The problem persists regardless of the 8.x MySQL client library I use to build DBD::mysql
(I've tried several), so I believe the problem is related to what has been changed from version 5.002 to version 5.003. The problem does not manifest itself in 5.002 or when using version 4.050.
The output of the program above is attached:
Other information
In version 5.003 mysql_library_end()
was added. Removing this line "fixes" the issue, although there may be other side effects of removing this line (memory leaks?). At the very least this sub is probably being called prematurely as it appears to remove plugins (like openssl plugin that apparently resets the TLS context):
static void deinit(mysql_harness::PluginFuncEnv *) {
// let the TlsLibraryContext destructor do the SSL cleanup
tls_library_context.reset();
}
Incidentally, it appears that dbd_db_destroy()
is being invoked when a database handle goes out scope in either a closure or a sub. This implies you probably should not be calling mysql_library_end()
in that subroutine?
dbd_discon_all
might be the appropriate place to call mysql_library_end()
but it appears to have been disabled back in 2003. You should also know that mysql_server_end()
is called in dbd_discon_all()
already. (mysql_server_end
is an alias for mysql_library_end()
).
Are both Perl and MySQL using libssl.so.1.0.2k
? Or is MySQL using a bundled OpenSSL?
I assume this also fails with v5.006 or that you didn't test this version?
I also filed this: https://bugs.mysql.com/bug.php?id=115326
I assume this also fails with v5.006 or that you didn't test this version?
yes
Are both Perl and MySQL using
libssl.so.1.0.2k
? Or is MySQL using a bundled OpenSSL?
I'm sorry I don't quite understand the question. If you are asking if the MySQL library is using the same SSL library I can't answer. I would assume so - but I don't think this is germane to the problem. I think the problem is essentially that DBD::mysql
is calling mysql_library_end()
prematurely when closures and subs cause the dbd_db_destroy()
to be called.
Will you be releasing this version to CPAN soon?
Will you be releasing this version to CPAN soon?
This is scheduled for next week https://github.com/perl5-dbi/DBD-mysql/milestone/11