Doesn't use database from DSN if tls=true

[jpeirson]

Issue description

Using tls=true in the DSN causes the db name in the DSN to be ignored when queries are executed.

Example code

package main

import (
	"database/sql"
	"fmt"
	"os"

	_ "github.com/go-sql-driver/mysql" // import mysql driver
)

func main() {
	dsn := os.Args[1] // e.g. "test:mypass@tcp(myserver)/mydb?tls=true"
	db, err := sql.Open("mysql", dsn)
	if err != nil {
		panic(err)
	}

	var cipher, dbname, ignore sql.NullString
	db.QueryRow("SHOW SESSION STATUS LIKE 'Ssl_cipher';").Scan(&ignore, &cipher)
	err = db.QueryRow("SELECT DATABASE();").Scan(&dbname)
	if err != nil {
		panic(err) // no error occurs
	}

	fmt.Printf("Ssl_cipher = %s\n", cipher.String)
	fmt.Printf("DATABASE() = %s\n", dbname.String)
}

Edit: I modified the example to verify that no error occurs, and fixed to use NullString to handle null return value.

I've added an all-access test user to my MySQL server using:

create user 'test'@'%' identified with 'sha256_password' by 'mypass';
grant all privileges on *.* to 'test'@'%';
flush privileges;

With TLS turned off, this produces, as expected:

myapp "test:mypass@tcp(myserver)/mydb?tls=false"

Ssl_cipher = 
DATABASE() = mydb

With TLS turned on, this produces, which is unexpected:

myapp "test:mypass@tcp(myserver)/mydb?tls=true"

Ssl_cipher = ECDHE-RSA-AES128-GCM-SHA256
DATABASE() =

In the latter case, I'd expect DATABASE() = mydb. I can manually run a USE test; statement from my sample program, but it defeats the purpose of specifying the db name in the DSN, and in a real app, I'd have to run that prior to every statement to ensure newly created connections also use this db name.

Error log

No errors logged, that I could see.

Configuration

Driver version (or git SHA):
7daee5b

Go version:
go version go1.11.1 linux/amd64

Server version:
5.7.21-21-log MySQL Community Server (GPL)

Server OS:
Red Hat Enterprise Linux Server release 6.8 (Santiago)

[jpeirson]

This sounds similar to issue #825 but the commit in which this is fixed produces the same problem in my scenario.

[jpeirson]

Note that I can also reproduce this in v1.4.0 (d523deb).

[methane]

You didn't check error returned by db.QueryRow()

It says: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs.

You need to specify tls=skip-verify, not tls=true.
https://github.com/go-sql-driver/mysql#tls

[jpeirson]

The error check from QueryRow() was only excluded from my example. I've updated the example accordingly.

I can verify in my case that the certificate is valid and signed by a trusted CA, and I don't receive the x509 validation error in @methane 's case. Also, this can't be the case from my example since the connection is being made and I can successfully query and show output for SHOW SESSION STATUS.

[jpeirson]

Also, just as a check, using tls=skip-verify in my case, where the server-side TLS cert is signed using a trusted CA and matches the FQDN, I get the same behavior as if I use tls=true, where no database is selected.

[methane]

I can't reproduce. I can get right database name.
Have you customized MySQL auth settings?
Especially, what is your default auth plugin?

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_default_authentication_plugin

[jpeirson]

The default auth plugin is set to sha256_password, and I can verify that the user account I'm testing against also uses the default plugin (via select user,host,plugin from mysql.user;).

[methane]

It's very important information!
Can you try native_password for default auth plugin setting?

[jpeirson]

If I change the default auth plugin for the server to mysql_native_password, my sample test app works, which tests against a user identified with sha256_password. FWIW, it also works against a different user identified with mysql_native_password.

With the server's default set to sha256_password then I can reproduce the issue for a user with either plugin type.

Before I ask our db security team whether we can permanently change the default plugin auth to native, is there something in the go-sql-driver/mysql package that can be fixed to address this?

[methane]

Before I ask our db security team whether we can permanently change the default plugin auth to native, is there something in the go-sql-driver/mysql package that can be fixed to address this?

Yes. But it may take very long time to fix.
Auth is complicated and our review speed is slow.