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