Bug 1323305

Summary: Password not required to login as root to MariaDB
Product: Red Hat OpenStack Reporter: Chris Lincoln <clincoln>
Component: openstack-tripleo-heat-templatesAssignee: Michele Baldessari <michele>
Status: CLOSED ERRATA QA Contact: Arik Chernetsky <achernet>
Severity: medium Docs Contact:
Priority: high    
Version: 7.0 (Kilo)CC: dbecker, dchia, dciabrin, dmatthew, dyasny, fdinitto, jguiditt, jjoyce, jstransk, mbayer, mburns, mcornea, michele, morazi, pkomarov, rhel-osp-director-maint, scorcora, tvignaud, ushkalim
Target Milestone: gaKeywords: Security
Target Release: 9.0 (Mitaka)   
Hardware: x86_64   
OS: Linux   
Fixed In Version: openstack-tripleo-heat-templates-2.0.0-9.el7ost Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1340208 1340210 (view as bug list) Environment:
Last Closed: 2016-08-11 11:30:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1340208, 1340210    

Description Chris Lincoln 2016-04-01 20:02:28 UTC
Description of problem:
We looked at the changes to MySQL (with OSP 7.2 binaries and templates) and saw that a random 10 character password is being passed into hiera for the MySQL root user.  The problem we are seeing is that a password is still not required to login as root to the database:

MariaDB [(none)]> select user,password from mysql.user;
| user     | password                                  |
| root     |                                           |
| root     |                                           |
|          |                                           |

Looking into it, it seems that the reason the password is not set is due to the order in which Galera is configured and then later started by Pacemaker.  Here is the mysql::server::root_password puppet class:

class mysql::server::root_password {

  $options = $mysql::server::options

  # manage root password if it is set
  if $mysql::server::create_root_user == true and $mysql::server::root_password != 'UNSET' {
    mysql_user { 'root@localhost':
      ensure        => present,
      password_hash => mysql_password($mysql::server::root_password),

  if $mysql::server::create_root_my_cnf == true and $mysql::server::root_password != 'UNSET' {
    file { "${::root_home}/.my.cnf":
      content => template('mysql/my.cnf.pass.erb'),
      owner   => 'root',
      mode    => '0600',
    if $mysql::server::create_root_user == true {
      Mysql_user['root@localhost'] -> File["${::root_home}/.my.cnf"]


First off, the variable create_root_user is set to false in the overcloud_controller_pacemaker.pp manifest that is run in an HA overcloud, along with create_root_my_cnf.  Even if these are set to true, in this step of the manifest (step 1), the database is not yet started, and will not be started until later in the next step (step 2).  In our testing, you also can't just call the mysql::server::root_password class in step 2 as that is a duplicate declaration.

Expected results:
Password prompted to login to MariaDB as root

Additional info:
Related to:

Comment 5 Michael Bayer 2016-05-05 14:54:52 UTC
OK so there is a canonical way to solve this Galera chicken/egg problem of root user not set up, but then once Galera is running it's not that simple to set up a root user because the user replication gets in the way.   The step that would have to be added is that mysqld is run temporarily in non-wsrep mode (easiest way is pass --wsrep-provider=none), then the password setup for root occurs, then you stop mysqld so that it can be started in wsrep mode.  

Looking at the puppet setup here, which keep in mind my experience reading puppet code started about a week ago, I would imagine the approach would be a new exec {} operation that essentially would have to take place within root_password.  We'd probably like the actual code to be local to overcloud_controller_pacemaker.pp so I suppose in puppet terms this means we'd create a new "class mysql::server::root_password" to override the one that's in tripleo-heat-templates.   I'm not sure how easy it is to "wrap" an existing operation in puppet vs. lift-and-copy.  With lift-and-copy we'd have to keep an eye on changes to this function in subsequent versions as there seem to be a bunch to the root_password method in the rhos-8.0 version.

Comment 8 Michael Bayer 2016-05-10 18:14:49 UTC
we've done a plain tripleO install and noted the accounts are as follows:

MariaDB [(none)]> select user,password,host from mysql.user;
| user     | password                                  | host                   |
| root     |                                           | localhost              |
| root     |                                           | overcloud-controller-1 |
| keystone | *D2247B46A5AA8FAEE048E647F127D89B2C48AC2A |              |
| keystone | *D2247B46A5AA8FAEE048E647F127D89B2C48AC2A | %                      |
|          |                                           | overcloud-controller-1 |
| heat     | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 | %                      |
| heat     | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 |              |
| gnocchi  | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 | %                      |
| gnocchi  | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 |              |
| cinder   | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 |              |
| cinder   | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 |             |
| cinder   | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 | %                      |
| neutron  | *4C1878ED41D83ED1199798FC138B8794C7AF165F |             |
| sahara   | *8B57208506727DF21DF4367E3EEA7F2023525076 |             |
| sahara   | *8B57208506727DF21DF4367E3EEA7F2023525076 |              |
| sahara   | *8B57208506727DF21DF4367E3EEA7F2023525076 | %                      |
| nova     | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | %                      |
| gnocchi  | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 |             |
| neutron  | *4C1878ED41D83ED1199798FC138B8794C7AF165F | %                      |
| nova     | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 |             |
| nova     | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 |              |
| neutron  | *4C1878ED41D83ED1199798FC138B8794C7AF165F |              |
| heat     | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 |             |
| nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 |              |
| nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | %                      |
| nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 |             |
| glance   | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 | %                      |
| glance   | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 |             |
| glance   | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 |              |
| keystone | *D2247B46A5AA8FAEE048E647F127D89B2C48AC2A |             |
30 rows in set (0.00 sec)

the password should be set for both of the "root" logins.  Additionally, the "anonymous" user, i.e. the one without a username, should be either removed, or given a password; this account is the "anonymous user" account and while it has low privileges, it's not necessary.

Additionally, as outlined in bz#1322095, "root" is also in /etc/sysconfig/clustercheck.  This username should be a low-privilege "clustercheck" user also with a password; the password for that user also needs to be in the clustercheck file and should not be the "root" user.

If we can add a step to the pacemaker galera install where we temporarily start the MySQL daemon in non-wsrep mode, we can apply all three of these changes in series to the running daemon.

Comment 9 Michael Bayer 2016-05-11 00:10:51 UTC
so today, Michele, Damien and I spent a good stretch with our heads together to cobble something up for this, and we will be integrating bz#1322095 into this as well since we don't want our shiny new root password sticking out in a clustercheck config file (which we will also see if we can set to chmod 400).   Michele with help from Damien worked up a proof of concept on an undercloud he had lying around as we all watched on tmux and he is still trying to work out some races that are occurring.   We're working on the "install" path first, with considerations being made for how "upgrades" should work.

Comment 21 Dan Yasny 2016-08-05 19:31:59 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1364576 opened for the undercloud DB

Comment 24 errata-xmlrpc 2016-08-11 11:30:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.