Hi Krzysztof,

But as you said, mysql -uroot -p does not accept 1\23 password. So what will happen if you enter it with the modified version of mysql_secure_installation? It will be accepted and stored with the backslash, but the root won't be able to connect to the database using mysql client because it won't accept the password with the backslash. The how do you expect the Fix 1 to work?

There isn't any problem with client not being able handle backslashes, the installation script has trouble reading one from user input.

It's quite the problem when someone uses automatically generated passwords, it's like "hey i have copy-pasted password to set it, but when i try to copy-paste it to log in it doesn't let me in"

Right now i've tried inserting "12
3" (double backslash is escaped into single backslash in result) into script, it translates to "12\3" in the client.

I'm not quite sure what you mean. You will have the same – or even bigger – problem with copy-pasting if you modify the security_installation script.
Did you actually try it?
Lets re-iterate.
We use e.g. MariaDB 5.5.30 (or MySQL, all the same, only lines are different).
We modify the security script to use -r as your 'Fix 1' suggests.
We run mysql_security_installation.
It asks if we want to set a new one (we do), then it prompts for the new password (we enter 1\23 or paste it from the clipboard), then it asks again, we re-enter, reload the tables, exit.
Then we try to connect to the server using mysql -uroot -p
Which password do you suggest to enter in the prompt? The same paste of 1\23 surely doesn't work, so in this sense you haven't gained anything. Actually I don't know if any would work.

Please actually do try it yourself; no third scripts or automation, just mysql_security_installation and mysql command-line client.

"1\23" is the one which should and do work after adding "-r" parameter to all 3 read commands.

What "-r" does is treating backslash as regular \ character instead of let's say "\n" becoming newline or "\t" becoming tabulation, it definitely should not happen in a password.

PS: Tried it.

It doesn't make much sense.

Here is what you get if you just do

set password = password('123')

+------+-------------------------------------------+

| user | password                                  |

+------+-------------------------------------------+

| root | *23AE809DDACAF96AF0FD78ED04B6A265E05AA257 |

Same happens if you do

set password = password('1\23')

+------+-------------------------------------------+

| user | password                                  |

+------+-------------------------------------------+

| root | *23AE809DDACAF96AF0FD78ED04B6A265E05AA257 |

(understandably)

Same happens if you enter 123 or 1\23 in the current (unpatched) version of mysql_secure_installation:

+------+-------------------------------------------+

| user | password                                  |

+------+-------------------------------------------+

| root | *23AE809DDACAF96AF0FD78ED04B6A265E05AA257 |

All of these allow you to connect via mysql client using 123 as a password, also understandably.

Now, to be able to connect via mysql client using 1\23 as a password, you need to do

set password = password('1\\23');

And you'll get

+------+-------------------------------------------+

| user | password                                  |

+------+-------------------------------------------+

| root | *4D617476C30310C15DB73E333FA5CC4E555B3BDA |

But if you patch mysql_secure_installation the way you suggested, and then enter there 1\23 as a new password, you'll get this:

+------+-------------------------------------------+

| user | password                                  |

+------+-------------------------------------------+

| root | *6CE27BDC6F768BB235AA78F24453062FAEEC9A6F |

(and btw same happens if you enter 1
23 in the unpatched version).
There is no way mysql client should successfully connect using 1\23 now, since the stored encrypted password is obviously different from the one which does allow it to connect with 1\23 (*4D617476C30310C15DB73E333FA5CC4E555B3BDA, as described above)

If you are really able to do the described and still connect to the server, i can only attribute it either to an oddity of a library, or, which is rather frightening, to a possible security problem. If that's indeed so, please provide the similar data (encrypted password for each case), so we could see where things go wrong. It will probably deserve a separate report, though.

Meanwhile, the current request relates to the upstream issue, I suggest you to file it at bugs.mysql.com since we'd have to maintain compatibility with their version of the script anyway (otherwise many more things might break when people migrate).

Upd: well, thinking about it, maybe it's an oddity of my library, as there is no glaring obvious reason why the password set through mysql_secure_installation should produce a different hash. So maybe it just works for you, but not for me.

Patching process:
1. Open the file with VIM
2. Write ":%s/read pass/read -r pass/g", press Enter

Patched "1\23"

Unpached "1
23":

Unpached "1\23"

Patched "123"

Unpatched "123"

Patched "1\2\3\"

Unpached "1\\2\\3
"

Unpached "1\2\3\"

You can clearly see that all variants of single-backslash passwords passed to installation script become "123" after the script is done.
On my computer it works the way it should and i get results i expect both in patched and unpatched version.

To be honest i have no idea where did you get that from, i suggest checking it again:

Try typing "1\2\3" in the first prompt, then "123" in retyping, the script will pass through setting "123" password.

I figured it out, it seems to be caused by an old bug in dash https://bugs.launchpad.net/ubuntu/+source/dash/+bug/259671 (which is ubuntu's sh, which is used by mysql_secure_installation). At some point mysql_secure_installation uses echo to escape the password line, and that's where the bug shows up.

elenst@ubuntu12-04:/data$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 24 16:29 /bin/sh -> dash

elenst@ubuntu12-04:/data$ /bin/sh
$ read -r p
1\23
$ echo $p
1�Ё
$ exit
elenst@ubuntu12-04:/data$ echo $SHELL
/bin/bash
elenst@ubuntu12-04:/data$ read -r p
1\23
elenst@ubuntu12-04:/data$ echo $p
1\23

Hence it's indeed a glitch of my system, yours works reasonably.

So, as said before, I recommend to file a bug report at bugs.mysql.com, as soon as they make a change it will be incorporated to the corresponding version of MariaDB.

Upd: I see you've already done it, MySQL:69044.

Reported already

Seems dash bug was ruled invalid. MySQL have a fix - migrating to a C++ version client/mysql_secure_installation.cc

alternately could #!/bin/bash at top.

There are other aspects of escaping that are also problematic in the script. Docker library fixes these with bash specific constructs - https://github.com/MariaDB/mariadb-docker/commit/58f4020613e4b96ab0a937890af1a7a4e0dc4b00.