Bug 1323305 - Password not required to login as root to MariaDB
Summary: Password not required to login as root to MariaDB
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 7.0 (Kilo)
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ga
: 9.0 (Mitaka)
Assignee: Michele Baldessari
QA Contact: Arik Chernetsky
URL:
Whiteboard:
Depends On:
Blocks: 1340208 1340210
TreeView+ depends on / blocked
 
Reported: 2016-04-01 20:02 UTC by Chris Lincoln
Modified: 2019-10-10 11:46 UTC (History)
18 users (show)

Fixed In Version: openstack-tripleo-heat-templates-2.0.0-9.el7ost
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1340208 1340210 (view as bug list)
Environment:
Last Closed: 2016-08-11 11:30:21 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:1599 normal SHIPPED_LIVE Red Hat OpenStack Platform 9 director Release Candidate Advisory 2016-08-11 15:25:37 UTC
OpenStack gerrit 319200 None None None 2016-06-07 14:35:18 UTC
OpenStack gerrit 319430 None None None 2016-06-07 14:34:33 UTC
Red Hat Bugzilla 1261303 None None None 2019-10-02 21:47:51 UTC
Red Hat Bugzilla 1289310 None CLOSED Create random password for rabbitmq guest user 2019-10-02 21:47:49 UTC
Launchpad 1581677 None None None 2016-05-13 21:36:24 UTC

Internal Links: 1261303 1289310

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:
https://bugzilla.redhat.com/show_bug.cgi?id=1261303
https://bugzilla.redhat.com/show_bug.cgi?id=1289310

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 | 192.0.2.6              |
| keystone | *D2247B46A5AA8FAEE048E647F127D89B2C48AC2A | %                      |
|          |                                           | overcloud-controller-1 |
| heat     | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 | %                      |
| heat     | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 | 192.0.2.6              |
| gnocchi  | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 | %                      |
| gnocchi  | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 | 192.0.2.6              |
| cinder   | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 | 192.0.2.6              |
| cinder   | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 | 192.0.2.10             |
| cinder   | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 | %                      |
| neutron  | *4C1878ED41D83ED1199798FC138B8794C7AF165F | 192.0.2.10             |
| sahara   | *8B57208506727DF21DF4367E3EEA7F2023525076 | 192.0.2.10             |
| sahara   | *8B57208506727DF21DF4367E3EEA7F2023525076 | 192.0.2.6              |
| sahara   | *8B57208506727DF21DF4367E3EEA7F2023525076 | %                      |
| nova     | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | %                      |
| gnocchi  | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 | 192.0.2.10             |
| neutron  | *4C1878ED41D83ED1199798FC138B8794C7AF165F | %                      |
| nova     | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | 192.0.2.10             |
| nova     | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | 192.0.2.6              |
| neutron  | *4C1878ED41D83ED1199798FC138B8794C7AF165F | 192.0.2.6              |
| heat     | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 | 192.0.2.10             |
| nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | 192.0.2.6              |
| nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | %                      |
| nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | 192.0.2.10             |
| glance   | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 | %                      |
| glance   | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 | 192.0.2.10             |
| glance   | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 | 192.0.2.6              |
| keystone | *D2247B46A5AA8FAEE048E647F127D89B2C48AC2A | 192.0.2.10             |
+----------+-------------------------------------------+------------------------+
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.

https://rhn.redhat.com/errata/RHEA-2016-1599.html


Note You need to log in before you can comment on or make changes to this bug.