[MDEV-25197] The statement set password=password('') executed in PS mode fails in case it is run by a user with expired password Created: 2021-03-19  Updated: 2021-04-14  Resolved: 2021-04-13

Status: Closed
Project: MariaDB Server
Component/s: Prepared Statements
Affects Version/s: 10.4, 10.5, 10.6
Fix Version/s: 10.4.19, 10.5.10, 10.6.0

Type: Bug Priority: Major
Reporter: Dmitry Shulga Assignee: Dmitry Shulga
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Blocks
blocks MDEV-16708 Unsupported commands for prepared sta... Closed
Relates
relates to MDEV-25413 should_send_column_info(): Assertion ... Closed

 Description   

A user with an expired password connected to a server can't assign new password with the statement "SET password=..." if the statement is run in PS mode, for example when it is submitted to server via binary protocol.

Test case is below.

CREATE USER user1@localhost PASSWORD EXPIRE
SET GLOBAL disconnect_on_expired_password=OFF;
connect(con1,localhost,user1);
connection con1;
--error ER_MUST_CHANGE_PASSWORD
select 1;
 
-- The following statement fails with the error ER_MUST_CHANGE_PASSWORD.
PREPARE stmt FROM "SET password=password('')";

In case the statement

SET password=password('');

is run as a regular statement it is executed successfully.



 Comments   
Comment by Oleksandr Byelkin [ 2021-04-06 ]

OK to push, but please merge all commits in one befor doing it.

Comment by Dmitry Shulga [ 2021-04-13 ]

Please don't forget to apply the following change set against 10.6.
This change set wasn't applied for 10.4 and 10.5 since the data member

  thd->cur_stm

was added only in 10.6

--- a/sql/sql_prepare.cc
+++ b/sql/sql_prepare.cc
@@ -4386,6 +4386,7 @@ bool Prepared_statement::prepare(const char *packet, uint packet_len)
     thd->restore_backup_statement(this, &stmt_backup);
     thd->restore_active_arena(this, &stmt_backup);
     thd->stmt_arena= old_stmt_arena;
+    thd->cur_stmt = save_cur_stmt;
     my_error(ER_MUST_CHANGE_PASSWORD, MYF(0));
     DBUG_RETURN(true);
   }

Generated at Thu Feb 08 09:35:52 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.