B.3. MySQL Permissions & Grant Tables

Note

The following portion of documentation comes from my answer to an old discussion of Keystone, a cool product that does trouble-ticket tracking for IT departments. I wrote this post to the Keystone support group regarding MySQL grant table permissions, and how to use them effectively. It is badly in need of updating, as I believe MySQL has added a field or two to the grant tables since this time, but it serves as a decent introduction and troubleshooting document for grant table issues. I used Keynote to track my troubles until I discovered Bugzilla, which gave me a whole new set of troubles to work on : ) Although it is of limited use, it still has SOME use, thus it's still included.

Please note, however, that I was a relatively new user to MySQL at the time. Some of my suggestions, particularly in how to set up security, showed a terrible lack of security-related database experience.

From matt_barnson@singletrac.com Wed Jul 7 09:00:07 1999
    Date: Mon, 1 Mar 1999 21:37:04 -0700 From: Matthew Barnson
    matt_barnson@singletrac.com To: keystone-users@homeport.org Subject:
    [keystone-users] Grant Tables FAQ [The following text is in the
    "iso-8859-1" character set] [Your display is set for the "US-ASCII"
    character set] [Some characters may be displayed incorrectly] Maybe we
    can include this rambling message in the Keystone FAQ? It gets asked a
    lot, and the only option current listed in the FAQ is
    "--skip-grant-tables". Really, you can't go wrong by reading section 6 of
    the MySQL manual, at http://www.mysql.com/Manual/manual.html. I am sure
    their description is better than mine. MySQL runs fine without
    permissions set up correctly if you run the mysql daemon with the
    "--skip-grant-tables" option. Running this way denies access to nobody.
    Unfortunately, unless you've got yourself firewalled it also opens the
    potential for abuse if someone knows you're running it. Additionally, the
    default permissions for MySQL allow anyone at localhost access to the
    database if the database name begins with "test_" or is named "test"
    (i.e. "test_keystone"). You can change the name of your database in the
    keystone.conf file ($sys_dbname). This is the way I am doing it for some
    of my databases, and it works fine. The methods described below assume
    you're running MySQL on the same box as your webserver, and that you
    don't mind if your $sys_dbuser for Keystone has superuser access. See
    near the bottom of this message for a description of what each field
    does. Method #1: 1. cd /var/lib #location where you'll want to run
    /usr/bin/mysql_install_db shell script from to get it to work. 2. ln -s
    mysql data # soft links the "mysql" directory to "data", which is what
    mysql_install_db expects. Alternately, you can edit mysql_install_db and
    change all the "./data" references to "./mysql". 3. Edit
    /usr/bin/mysql_install_db with your favorite text editor (vi, emacs, jot,
    pico, etc.) A) Copy the "INSERT INTO db VALUES
    ('%','test\_%','','Y','Y','Y','Y','Y','Y');" and paste it immediately
    after itself. Chage the 'test\_%' value to 'keystone', or the value of
    $sys_dbname in keystone.conf. B) If you are running your keystone
    database with any user, you'll need to copy the "INSERT INTO user VALUES
    ('localhost','root','','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');" line
    after itself and change 'root' to the name of the keystone database user
    ($sys_dbuser) in keystone.conf. # adds entries to the script to create
    grant tables for specific hosts and users. The user you set up has
    super-user access ($sys_dbuser) -- you may or may not want this. The
    layout of mysql_install_db is really very uncomplicated. 4.
    /usr/bin/mysqladmin shutdown # ya gotta shut it down before you can
    reinstall the grant tables! 5. rm -i /var/lib/mysql/mysql/*.IS?' and
    answer 'Y' to the deletion questions. # nuke your current grant tables.
    This WILL NOT delete any other databases than your grant tables. 6.
    /usr/bin/mysql_install_db # run the script you just edited to install
    your new grant tables. 7. mysqladmin -u root password (new_password) #
    change the root MySQL password, or else anyone on localhost can login to
    MySQL as root and make changes. You can skip this step if you want
    keystone to connect as root with no password. 8. mysqladmin -u
    (webserver_user_name) password (new_password) # change the password of
    the $sys_dbuser. Note that you will need to change the password in the
    keystone.conf file as well in $sys_dbpasswd, and if your permissions are
    set up incorrectly anybody can type the URL to your keystone.conf file
    and get the password. Not that this will help them much if your
    permissions are set to @localhost. Method #2: easier, but a pain
    reproducing if you have to delete your grant tables. This is the
    "recommended" method for altering grant tables in MySQL. I don't use it
    because I like the other way :) shell> mysql --user=root keystone
    mysql> GRANT
    SELECT,INSERT,UPDATE,DELETE,INDEX,ALTER,CREATE,DROP,RELOAD,SHUTDOWN,PROCESS,
    FILE, ON keystone.* TO <$sys_dbuser name>@localhost IDENTIFIED BY
    '(password)' WITH GRANT OPTION; OR mysql> GRANT ALL PRIVILEGES ON
    keystone.* TO <$sys_dbuser name>@localhost IDENTIFIED BY
    '(password)' WITH GRANT OPTION; # this grants the required permissions to
    the keystone ($sys_dbuser) account defined in keystone.conf. However, if
    you are runnning many different MySQL-based apps, as we are, it's
    generally better to edit the mysql_install_db script to be able to
    quickly reproduce your permissions structure again. Note that the FILE
    privelege and WITH GRANT OPTION may not be in your best interest to
    include. GRANT TABLE FIELDS EXPLANATION: Quick syntax summary: "%" in
    MySQL is a wildcard. I.E., if you are defining your DB table and in the
    'host' field and enter '%', that means that any host can access that
    database. Of course, that host must also have a valid db user in order to
    do anything useful. 'db'=name of database. In our case, it should be
    "keystone". "user" should be your "$sys_dbuser" defined in keystone.conf.
    Note that you CANNOT add or change a password by using the "INSERT INTO
    db (X)" command -- you must change it with the mysql -u command as
    defined above. Passwords are stored encrypted in the MySQL database, and
    if you try to enter it directly into the table they will not match.
    TABLE: USER. Everything after "password" is a privelege granted (Y/N).
    This table controls individual user global access rights.
    'host','user','password','select','insert','update','delete','index','alter'
    ,'create','drop','grant','reload','shutdown','process','file' TABLE: DB.
    This controls access of USERS to databases.
    'host','db','user','select','insert','update','delete','index','alter','crea
    te','drop','grant' TABLE: HOST. This controls which HOSTS are allowed
    what global access rights. Note that the HOST table, USER table, and DB
    table are very closely connected -- if an authorized USER attempts an SQL
    request from an unauthorized HOST, she's denied. If a request from an
    authorized HOST is not an authorized USER, it is denied. If a globally
    authorized USER does not have rights to a certain DB, she's denied. Get
    the picture?
    'host','db','select','insert','update','delete','index','alter','create','dr
    op','grant' You should now have a working knowledge of MySQL grant
    tables. If there is anything I've left out of this answer that you feel
    is pertinent, or if my instructions don't work for you, please let me
    know and I'll re-post this letter again, corrected. I threw it together
    one night out of exasperation for all the newbies who don't know squat
    about MySQL yet, so it is almost guaranteed to have errors. Once again,
    you can't go wrong by reading section 6 of the MySQL manual. It is more
    detailed than I! http://www.mysql.com/Manual/manual.html.