2003-03-11 10:41:53 +01:00
drop table if exists t1;
create table t1(f1 int);
insert into t1 values (5);
grant select on test.* to ssl_user1@localhost require SSL;
2004-12-01 02:35:02 +01:00
grant select on test.* to ssl_user2@localhost require cipher "DHE-RSA-AES256-SHA";
2010-01-29 14:55:46 +01:00
grant select on test.* to ssl_user3@localhost require cipher "DHE-RSA-AES256-SHA" AND SUBJECT "/C=SE/ST=Uppsala/O=MySQL AB";
grant select on test.* to ssl_user4@localhost require cipher "DHE-RSA-AES256-SHA" AND SUBJECT "/C=SE/ST=Uppsala/O=MySQL AB" ISSUER "/C=SE/ST=Uppsala/L=Uppsala/O=MySQL AB";
2006-08-22 14:29:48 +02:00
grant select on test.* to ssl_user5@localhost require cipher "DHE-RSA-AES256-SHA" AND SUBJECT "xxx";
2003-03-11 10:41:53 +01:00
flush privileges;
2006-08-22 14:29:48 +02:00
connect(localhost,ssl_user5,,test,MASTER_PORT,MASTER_SOCKET);
ERROR 28000: Access denied for user 'ssl_user5'@'localhost' (using password: NO)
2005-10-04 15:43:55 +02:00
SHOW STATUS LIKE 'Ssl_cipher';
Variable_name Value
Ssl_cipher DHE-RSA-AES256-SHA
2003-03-11 10:41:53 +01:00
select * from t1;
f1
5
delete from t1;
2005-03-31 21:03:26 +02:00
ERROR 42000: DELETE command denied to user 'ssl_user1'@'localhost' for table 't1'
2005-10-04 15:43:55 +02:00
SHOW STATUS LIKE 'Ssl_cipher';
Variable_name Value
Ssl_cipher DHE-RSA-AES256-SHA
2003-03-11 10:41:53 +01:00
select * from t1;
f1
5
delete from t1;
2005-03-31 21:03:26 +02:00
ERROR 42000: DELETE command denied to user 'ssl_user2'@'localhost' for table 't1'
2005-10-04 15:43:55 +02:00
SHOW STATUS LIKE 'Ssl_cipher';
Variable_name Value
Ssl_cipher DHE-RSA-AES256-SHA
2003-03-11 10:41:53 +01:00
select * from t1;
f1
5
delete from t1;
2005-03-31 21:03:26 +02:00
ERROR 42000: DELETE command denied to user 'ssl_user3'@'localhost' for table 't1'
2005-10-04 15:43:55 +02:00
SHOW STATUS LIKE 'Ssl_cipher';
Variable_name Value
Ssl_cipher DHE-RSA-AES256-SHA
2003-03-11 10:41:53 +01:00
select * from t1;
f1
5
delete from t1;
2005-03-31 21:03:26 +02:00
ERROR 42000: DELETE command denied to user 'ssl_user4'@'localhost' for table 't1'
2006-04-18 18:10:47 +02:00
drop user ssl_user1@localhost, ssl_user2@localhost,
2006-08-22 14:29:48 +02:00
ssl_user3@localhost, ssl_user4@localhost, ssl_user5@localhost;
2003-03-11 10:41:53 +01:00
drop table t1;
2006-05-03 14:06:34 +02:00
mysqltest: Could not open connection 'default': 2026 SSL connection error
mysqltest: Could not open connection 'default': 2026 SSL connection error
mysqltest: Could not open connection 'default': 2026 SSL connection error
2006-11-07 17:42:15 +01:00
SSL error: Unable to get private key from ''
2006-05-03 14:06:34 +02:00
mysqltest: Could not open connection 'default': 2026 SSL connection error
2006-11-07 17:42:15 +01:00
SSL error: Unable to get certificate from ''
2006-05-03 14:06:34 +02:00
mysqltest: Could not open connection 'default': 2026 SSL connection error
2007-04-02 13:12:59 +02:00
SHOW STATUS LIKE 'Ssl_cipher';
Variable_name Value
Ssl_cipher DHE-RSA-AES256-SHA
2007-03-28 12:23:55 +02:00
Variable_name Value
Ssl_cipher DHE-RSA-AES256-SHA
2007-04-05 22:38:57 +02:00
End of 5.0 tests
DROP TABLE IF EXISTS thread_status;
DROP EVENT IF EXISTS event_status;
SET GLOBAL event_scheduler=1;
CREATE EVENT event_status
ON SCHEDULE AT NOW()
ON COMPLETION NOT PRESERVE
DO
BEGIN
CREATE TABLE thread_status
SELECT variable_name, variable_value
FROM information_schema.session_status
WHERE variable_name LIKE 'SSL_ACCEPTS' OR
variable_name LIKE 'SSL_CALLBACK_CACHE_HITS';
END$$
SELECT variable_name, variable_value FROM thread_status;
variable_name variable_value
2008-11-18 17:45:44 +01:00
SSL_ACCEPTS #
SSL_CALLBACK_CACHE_HITS #
2007-04-05 22:38:57 +02:00
DROP TABLE thread_status;
SET GLOBAL event_scheduler=0;
2007-04-11 21:01:10 +02:00
SHOW STATUS LIKE 'Ssl_cipher';
Variable_name Value
Ssl_cipher AES128-SHA
SHOW STATUS LIKE 'Ssl_cipher';
Variable_name Value
Ssl_cipher AES128-SHA
mysqltest: Could not open connection 'default': 2026 SSL connection error
2007-04-11 23:42:53 +02:00
CREATE TABLE t1(a int);
INSERT INTO t1 VALUES (1), (2);
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
DROP TABLE IF EXISTS `t1`;
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
2007-04-11 23:42:53 +02:00
CREATE TABLE `t1` (
2007-04-12 14:29:10 +02:00
`a` int(11) DEFAULT NULL
2007-04-11 23:42:53 +02:00
);
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
/*!40101 SET character_set_client = @saved_cs_client */;
2007-04-11 23:42:53 +02:00
LOCK TABLES `t1` WRITE;
/*!40000 ALTER TABLE `t1` DISABLE KEYS */;
INSERT INTO `t1` VALUES (1),(2);
/*!40000 ALTER TABLE `t1` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
DROP TABLE IF EXISTS `t1`;
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
2007-04-11 23:42:53 +02:00
CREATE TABLE `t1` (
2007-04-12 14:29:10 +02:00
`a` int(11) DEFAULT NULL
2007-04-11 23:42:53 +02:00
);
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
/*!40101 SET character_set_client = @saved_cs_client */;
2007-04-11 23:42:53 +02:00
LOCK TABLES `t1` WRITE;
/*!40000 ALTER TABLE `t1` DISABLE KEYS */;
INSERT INTO `t1` VALUES (1),(2);
/*!40000 ALTER TABLE `t1` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
DROP TABLE IF EXISTS `t1`;
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
2007-04-11 23:42:53 +02:00
CREATE TABLE `t1` (
2007-04-12 14:29:10 +02:00
`a` int(11) DEFAULT NULL
2007-04-11 23:42:53 +02:00
);
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
/*!40101 SET character_set_client = @saved_cs_client */;
2007-04-11 23:42:53 +02:00
LOCK TABLES `t1` WRITE;
/*!40000 ALTER TABLE `t1` DISABLE KEYS */;
INSERT INTO `t1` VALUES (1),(2);
/*!40000 ALTER TABLE `t1` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
SSL error: Unable to get private key from 'MYSQL_TEST_DIR/std_data/client-cert.pem'
mysqldump: Got error: 2026: SSL connection error when trying to connect
DROP TABLE t1;
2008-11-18 17:45:44 +01:00
Variable_name Value
Ssl_cipher DHE-RSA-AES256-SHA
Variable_name Value
Ssl_cipher EDH-RSA-DES-CBC3-SHA
Variable_name Value
Ssl_cipher EDH-RSA-DES-CBC-SHA
Variable_name Value
Ssl_cipher RC4-SHA
select 'is still running; no cipher request crashed the server' as result from dual;
result
is still running; no cipher request crashed the server
2009-05-25 15:00:18 +02:00
GRANT SELECT ON test.* TO bug42158@localhost REQUIRE X509;
FLUSH PRIVILEGES;
SHOW STATUS LIKE 'Ssl_cipher';
Variable_name Value
Ssl_cipher DHE-RSA-AES256-SHA
DROP USER bug42158@localhost;
2008-11-18 17:45:44 +01:00
End of 5.1 tests
