Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

MySQL Root Password Discussion

On Tuesday, 28 March 2006, Alain, Tim, and Andy discussed possible ways to propagate a MySQL root password to the configure_* scripts that need it. This page is a record of that discussion.

Background

By default, MySQL has no password for its own root user, and a VDT installation does not set one. However, it is possible for a user to run configure_mysql with the --root command-line option to set the MySQL root password. Once this is done, any configure_* script that tries to run MySQL commands as the root user fails with an authorization failure.

Brainstorming Options

We began by brainstorming possible solutions and came up with:

  1. Make each configure_* script that cares take a new --db-password argument; users would have to supply the password on each invocation
  2. In configure_mysql, store the password to a file with 0400 permissions and make each configure_* script that cares read from that file
  3. In configure_mysql, store the password to a file, encrypt its contents, and make each configure_* script that cares read from that file
  4. Combine options above – support both an optional file and a command-line argument
  5. Create an authentication system where there's a root VDT password, standard suffixes for various components that need their own password, and a function to take the root password and a suffix and create a unique password for them
  6. Install and integrate an existing password keychain component into the VDT

Discussion

As far as we know, we only need to deal with the MySQL root password, so a system that manages multiple passwords (i.e., the last two options) seems like overkill right now. Maybe someday.

Mostly, the discussion boiled down to a decision between the first two options. The good thing about the command-line switch option is that there's no real security hole – but then we remembered that anyone could use ps to see the password. The good thing about the file option is that it covers the use case in which the user installs one component (e.g., VOMS), sets a MySQL root password, then installs another component. However, it is clearly less secure.

In the end, with some advice from Jim Kupsch, we settled on a new option. To VDTConfigure.pm, we'll add a function that will prompt the user for the MySQL root password if one appears to be needed. This replaces the command-line switch idea, so that we avoid making the MySQL root password visible in ps commands, at least in our own scripts. A configure_* script that cares can call this function and save the result, using it throughout the script as needed. For installations, we'll have to change the invocations of these scripts from using shell() to shellDialogue(), because we need the interactive component. Later, if users really want us to save the password to a file, it will be easy to add to the one central function. Finally, configure_mysql will warn users about remembering their password and make sure they want to continue.

We expect to make and test these changes for VDT 1.3.11.