1. 前言
Mysql數據庫安全配置、或者叫加固屬於風險模型中的一環，它需要安全人員在理論和實踐的學習中不斷發現新的問題，並針對這些問題對數據的各個方面的配置進行強化。本文試圖圍繞著數據庫風險識別、數據庫安全加固這個問題，探討可以采取的措施來最大程度的保證我們的數據庫的安全控制處在一個較好的水平。
2. Mysql賬戶權限安全
mysql中存在4個控制權限的表，分別為
1. mysql.USER表
2. mysql.DB表
3. mysql.TABLES_PRIV表
4. mysql.COLUMNS_PRIV表
要注意的是，Mysql中有一個數據庫"information_schema"，似乎裡面保存的也是一些權限信息，但是要明白的是，這個數據庫"information_schema"是為系統管理員提供元數據的一個簡便方式，它實際上是一個視圖，可以理解為對Mysql中的一個信息的封裝，對於Mysql主程序來說，身份認證和授權的信息的來源只有一個，就是"mysql"。
http://www.cnblogs.com/hzhida/archive/2012/08/08/2628826.html
0×1. mysql.USER表
select * from USER;
desc USER;
mysql> desc USER;+-------------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------------------+------+-----+---------+-------+
| Host | char(60) | NO | PRI | | |
| User | char(16) | NO | PRI | | |
| Password | char(41) | NO | | | |
| Select_priv | enum('N','Y') | NO | | N | |
| Insert_priv | enum('N','Y') | NO | | N | |
| Update_priv | enum('N','Y') | NO | | N | |
| Delete_priv | enum('N','Y') | NO | | N | |
| Create_priv | enum('N','Y') | NO | | N | |
| Drop_priv | enum('N','Y') | NO | | N | |
| Reload_priv | enum('N','Y') | NO | | N | |
| Shutdown_priv | enum('N','Y') | NO | | N | |
| Process_priv | enum('N','Y') | NO | | N | |
| File_priv | enum('N','Y') | NO | | N | |
| Grant_priv | enum('N','Y') | NO | | N | |
| References_priv | enum('N','Y') | NO | | N | |
| Index_priv | enum('N','Y') | NO | | N | |
| Alter_priv | enum('N','Y') | NO | | N | |
| Show_db_priv | enum('N','Y') | NO | | N | |
| Super_priv | enum('N','Y') | NO | | N | |
| Create_tmp_table_priv | enum('N','Y') | NO | | N | |
| Lock_tables_priv | enum('N','Y') | NO | | N | |
| Execute_priv | enum('N','Y') | NO | | N | |
| Repl_slave_priv | enum('N','Y') | NO | | N | |
| Repl_client_priv | enum('N','Y') | NO | | N | |
| Create_view_priv | enum('N','Y') | NO | | N | |
| Show_view_priv | enum('N','Y') | NO | | N | |
| Create_routine_priv | enum('N','Y') | NO | | N | |
| Alter_routine_priv | enum('N','Y') | NO | | N | |
| Create_user_priv | enum('N','Y') | NO | | N | |
| Event_priv | enum('N','Y') | NO | | N | |
| Trigger_priv | enum('N','Y') | NO | | N | |
| Create_tablespace_priv | enum('N','Y') | NO | | N | |
| ssl_type | enum('','ANY','X509','SPECIFIED') | NO | | | |
| ssl_cipher | blob | NO | | NULL | |
| x509_issuer | blob | NO | | NULL | |
| x509_subject | blob | NO | | NULL | |
| max_questions | int(11) unsigned | NO | | 0 | |
| max_updates | int(11) unsigned | NO | | 0 | |
| max_connections | int(11) unsigned | NO | | 0 | |
| max_user_connections | int(11) unsigned | NO | | 0 | |
| plugin | char(64) | YES | | | |
| authentication_string | text | YES | | NULL | |
| password_expired | enum('N','Y') | NO | | N | |
+-------------------------------+------+-----+---------+-------+
0×2. mysql.DB表
select * from DB;
desc DB;
mysql> desc DB; +-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+------+-----+---------+-------+
| Host | char(60) | NO | PRI | | |
| Db | char(64) | NO | PRI | | |
| User | char(16) | NO | PRI | | |
| Select_priv | enum('N','Y') | NO | | N | |
| Insert_priv | enum('N','Y') | NO | | N | |
| Update_priv | enum('N','Y') | NO | | N | |
| Delete_priv | enum('N','Y') | NO | | N | |
| Create_priv | enum('N','Y') | NO | | N | |
| Drop_priv | enum('N','Y') | NO | | N | |
| Grant_priv | enum('N','Y') | NO | | N | |
| References_priv | enum('N','Y') | NO | | N | |
| Index_priv | enum('N','Y') | NO | | N | |
| Alter_priv | enum('N','Y') | NO | | N | |
| Create_tmp_table_priv | enum('N','Y') | NO | | N | |
| Lock_tables_priv | enum('N','Y') | NO | | N | |
| Create_view_priv | enum('N','Y') | NO | | N | |
| Show_view_priv | enum('N','Y') | NO | | N | |
| Create_routine_priv | enum('N','Y') | NO | | N | |
| Alter_routine_priv | enum('N','Y') | NO | | N | |
| Execute_priv | enum('N','Y') | NO | | N | |
| Event_priv | enum('N','Y') | NO | | N | |
| Trigger_priv | enum('N','Y') | NO | | N | |
+-------------+------+-----+---------+-------+
0×3. mysql.TABLES_PRIV表
select * from TABLES_PRIV;
desc TABLES_PRIV;
mysql> desc TABLES_PRIV;
+------------------+------+-----+--------------------+
| Field | Type | Null | Key | Default | Extra |
+------------------+------+-----+--------------------+
| Host | char(60) | NO | PRI | | |
| Db | char(64) | NO | PRI | | |
| User | char(16) | NO | PRI | | |
| Table_name | char(64) | NO | PRI | | |
| Grantor | char(77) | NO | MUL | | |
| Timestamp | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| Table_priv | set('Select','Insert','Update','Delete','Create','Drop','Grant','References','Index','Alter','Create View','Show view','Trigger') | NO | | | |
| Column_priv | set('Select','Insert','Update','References') | NO | | | |
+------------------+------+-----+--------------------+
0×4. mysql.COLUMNS_PRIV表
select * from COLUMNS_PRIV;
desc COLUMNS_PRIV;
mysql> desc COLUMNS_PRIV; +----+------+-----+--------------------+
| Field | Type | Null | Key | Default | Extra |
+----+------+-----+--------------------+
| Host | char(60) | NO | PRI | | |
| Db | char(64) | NO | PRI | | |
| User | char(16) | NO | PRI | | |
| Table_name | char(64) | NO | PRI | | |
| Column_name | char(64) | NO | PRI | | |
| Timestamp | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| Column_priv | set('Select','Insert','Update','References') | NO | | | |
+----+------+-----+--------------------+
以上是這4個表的基本結構，在我們進行數據庫連接、登錄的時候，mysql權限表的驗證過程為：
1. 先從user表中的:
1) Host
2) User
3) Password
這3個字段中判斷連接的ip、用戶名、密碼是否存在，存在則通過驗證。
2. 通過身份認證後，進行權限分配，按照:
1) user
2) db
3) tables_priv
4) columns_priv
的順序進行驗證。
即先檢查全局權限表user，如果user中對應的權限為Y，則此用戶對所有數據庫的權限都為Y，將不再檢查db，tables_priv,columns_priv
如果全局權限表user對應的權限為N，則到db表中檢查此用戶對應的具體數據庫，並得到db中為Y的權限
如果db中為N，則檢查tables_priv中此數據庫對應的具體表，取得表中的權限Y，以此類推。逐級下降
用流程圖表示如下：
了解了Mysql的賬戶權限原理和判斷流程，我們接下來需要了解就是應該以怎樣的方式去進行權限配置，才能達到所謂的"最小權限原則"呢？Mysql的賬戶權限優先級順序是:
user->db->tables_priv->columns_pri
稍作思考，我們可以發現，這些表的作用本質上是一樣的，區別就在於它們的作用域范圍不同，從user到columns_pri逐級作用域范圍降低，因此控制粒度也增大，它們的配置遵循"就近原則"，即以優先級最低的那個為准，所以，我們在進行Mysql的賬戶權限安全配置的時候會發現"我們似乎在做很多重復性的工作"。但我們要明白的，Mysql的這種逐層次的權限配置體系為我們提供了一個細粒度的控制方法。所以我們的權限配置也應該按照這個順序來有規劃地進行。
0×1. USER表
權限
權限級別
權限說明
使用賬戶是否給予
CREATE
數據庫、表或索引
創建數據庫、表或索引權限
建議給與
DROP
數據庫或表
刪除數據庫或表權限
建議給與
GRANT OPTION
數據庫、表或保存的程序
賦予權限選項
不建議給與
REFERENCES
數據庫或表
無
不建議給與
ALTER
表
更改表，比如添加字段、索引等
建議給與
DELETE
表
刪除數據權限
建議給與
INDEX
表
索引權限
建議給與
INSERT
表
插入權限
建議給與
SELECT
表
查詢權限
建議給與
UPDATE
表
更新權限
建議給與
CREATE VIEW
視圖
創建視圖權限
建議給與
SHOW VIEW
視圖
查看視圖權限
建議給與
ALTER ROUTINE
存儲過程
更改存儲過程權限
不建議給與
CREATE ROUTINE
存儲過程
創建存儲過程權限
不建議給與
EXECUTE
存儲過程
執行存儲過程權限
不建議給與
FILE
服務器主機上的文件訪問
文件訪問權限
不建議
CREATE TEMPORARY TABLES
服務器管理
創建臨時表權限
不建議
LOCK TABLES
服務器管理
鎖表權限
不建議給與
CREATE USER
服務器管理
創建用戶權限
不建議給與
PROCESS
服務器管理
查看進程權限
不建議給與
RELOAD
服務器管理
執行flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables, flush-threads, refresh, reload等命令的權限
不建議給與
REPLICATION CLIENT
服務器管理
復制權限
不建議給與
REPLICATION SLAVE
服務器管理
復制權限
不建議給與
SHOW DATABASES
服務器管理
查看數據庫列表權限
不建議給與
SHUTDOWN
服務器管理
關閉數據庫權限
不建議給與
SUPER
服務器管理
執行kill線程權限
不建議給與
從表格中可以看到，USER表主要針對數據庫的賬戶進行粗粒度的權限控制，定義了"某人允許做什麼事"。
0×2. DB表
權限
說明
網站使用賬戶是否給予
Select
可對其下所有表進行查詢
建議給予
Insert
可對其下所有表進行插入
建議給予
Update
可對其下所有表進行更新
建議給予
Delete
可對其下所有表進行刪除
建議給予
Create
可在此數據庫下創建表或者索引
建議給予
Drop
可刪除此數據庫，及此數據庫下的表
不建議給予
Grant
賦予權限選項
不建議給予
References
未來MySQL特性的占位符
不建議給予
Index
可對其下的所有表進行索引
建議給予
Alter
可對其下的所有表進行更改
建議給予
Create_tmp_table
創建臨時表
不建議給予
Lock_tables
可對其下所有表進行鎖定
不建議給予
Create_view
可在此數據下創建視圖
建議給予
Show_view
可在此數據下查看視圖
建議給予
Create_routine
可在此數據下創建存儲過程
不建議給予
Alter_routine
可在此數據下更改存儲過程
不建議給予
Execute
可在此數據下執行存儲過程
不建議給予
Event
可在此數據下創建事件調度器
不建議給予
Trigger
可在此數據下創建觸發器
不建議給予
DB表可以看成是USER表對權限控制的一個補充，一個更細粒度地、針對數據庫庫級別的權限控制。
同時，DB表也隱式包含了將賬戶限定在某個數據庫的范圍內這個配置，即限制某個用戶只能用對它自己的數據庫的控制權，對不屬於它的數據庫禁止操作，這能有效防止橫向越權的發生。
mysql> select host,db,user from db;
+------+---------+------+
| host | db | user |
+------+---------+------+
| % | test | |
| % | test\_% | |
+------+---------+------+
可以看到，user字段為空，表示當前不對用戶做任何數據庫屬權限制，在網站的部署過程中，應該單獨針對網站建立一個賬戶一個獨立的數據庫，並為這個賬戶分配唯一的專屬數據庫，防止網絡被入侵後的橫向、縱向提權。
對於Mysql中的賬戶權限相關的安全配置，總結如下：
1. 針對每個網站建立一個單獨的賬戶
2. 為每個網站單獨建立一個專屬數據庫(雖然DEDE、DZ普通采用表前綴的方法來實現"一庫多站"，但好的做法還是"一庫一站")
3. 按照user->db->tables_priv->columns_pri的順序進行細粒度的權限控制
4. 為每個用戶單獨配置一個專屬數據庫，保證當前用戶的所有操作只能發生在它自己的數據庫中，防止SQL注入發生後，黑客通過注入點訪問到系統表
賬戶權限安全配置需要的常用命令
1. 新建一個用戶並給予相應數據庫的權限
grant select,insert,update,delete,create,drop privileges on database.* to user@localhost identified by 'passwd';
grant all privileges on database.* to user@localhost identified by 'passwd';
2. 刷新權限
flush privileges;
3. 顯示授權
show grants;
4. 移除授權
revoke delete on *.* from 'user'@'localhost';
5. 刪除用戶
drop user 'user'@'localhost';
6. 給用戶改名
rename user 'jack'@'%' to 'jim'@'%';
7. 給用戶改密碼
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('123456');
3. Mysql數據的網絡安全配置
對數據庫所在的DMZ的網絡拓樸的安全配置也是我們在進行安全評估的時候需要考慮的一個方面，這對防御內網掃描、網絡攻擊有一定幫助。
0×1: 限制訪問Mysql端口的IP
對Mysql的訪問IP的限制，可以從應用層和主機層來分別達到目的
1. 主機層:
1) windows可以通過windows防火牆
2) Linux下可以通過iptables
來限制允許訪問mysql端口的IP地址
//只允許指定的IP進行訪問
iptables -A INPUT -p tcp -s xxxx.xxxx.xxxx.xxxx/24 --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp -s xxxx.xxxx.xxxx.xxxx/24 --dport 3306 -j ACCEPT
..
iptables -P INPUT DROP
可以看到，這種方法的缺點是硬編碼導致靈活性低，如果mysql的默認端口3306被修改了(例如8890)，則這條iptables規則也需要相應的修改
mysql> select host,user,password from user;
+-----------+------+----------------+
| host | user | password |
+-----------+------+----------------+
| localhost | root | *832EB84CB764129D05D498ED9CA7E5CE9B8F83EB |
| . | root | *832EB84CB764129D05D498ED9CA7E5CE9B8F83EB |
| :: | root | *832EB84CB764129D05D498ED9CA7E5CE9B8F83EB |
| localhost | | |
+-----------+------+----------------+
這幾行記錄表明了root這個賬戶只能是本機登錄，在部署的過程中，我們可以為指定賬戶添加某個安全的跳板機，並保證這個跳板機IP是不變的。
0×2: 修改mysql的端口
windows下可以修改配置文件my.ini來實現，linux可以修改配置文件my.cnf來實現。
port = 3306
對mysql端口的修改可以從一定程度上防止端口掃描工具的掃描。
0×3: 限制連接用戶的數量
數據庫的某用戶多次遠程連接，會導致性能的下降和影響其他用戶的操作，有必要對其進行限制。可以通過限制單個賬戶允許的連接數量來實現，設置my.cnf文件的mysqld中的max_user_connections變量來完成。GRANT語句也可以支持資源控制選項來限制服務器對一個賬戶允許的使用范圍。
#vi /etc/my.cnf
[mysqld]
max_user_connections 2
4. 密碼策略安全
這裡所謂的密文策略安全包括Mysql自身的賬戶密碼的安全、也包括網站用戶的密碼安全。
0×1: mysql賬戶密碼
因為mysql本身沒有抗窮舉的帳號鎖定機制，所以對於mysql自身的登錄帳號，尤其是root帳號，需要遵循"密碼強度策略"設置高強度的密碼，保證攻擊者從窮舉帳號攻擊這條路無法獲得合適的投資收益比。
0×2: 網站用戶的密碼
數據庫管理員無法規定用戶的網站使用什麼樣的密碼策略，這完全取決於用戶自己的編碼習慣、或者說是站長所使用的CMS的編碼習慣。這方面，mysql無法做的更多，但也許可以做的是建立一個針對網站密碼窮舉、脫庫攻擊的日志追溯系統，當發生脫庫攻擊時能第一時間給用戶提供"事發現場"的更多信息。或者數據庫管理員主動進行可控的撞庫測試，提前幫助用戶發生潛在的撞庫、脫庫風險。
5. Mysql日志
啟動Mysql的日志不僅可以為我們提供性能熱點的分析，還可以幫助我們加固Mysql數據庫的安全，例如:
1. 從日志中獲得典型SQL注入語句
2. 利用正則模型從日志中捕獲注入攻擊的發生
3. 在脫庫、數據洩漏之後獲得關於受攻擊數據庫的情況、洩漏范圍等數據
mysql有以下幾種日志，它們都在my.ini中進行配置：
1. 錯誤日志：-log-err
log-error=E:/wamp/logs/mysql_error.log
2. 查詢日志(記錄所有SQL語句)：-log
log=E:/wamp/logs/mysql.log
3. 慢查詢日志：-log-slow-queries
1) 查看慢查詢時間
show variables like "long_query_time";默認10s
2) 查看慢查詢配置情況
show status like "%slow_queries%";
3) 查看慢查詢日志路徑
show variables like "%slow%";
//存儲位置、長SQL的阈值
E:\wamp\bin\mysql\mysql5.6.12\data\LittleHann-PC-slow.log
long_query_time=5
4. 更新日志：-log-update
5. 二進制日志：-log-bin//記錄除select語句之外的所有sql語句到日志中，可以用來恢復數據文件log-bin=E:/wamp/logs/bin
查看日志開啟情況:
show variables like 'log_%';
+-------------------------------------+
| Variable_name | Value |
+-------------------------------------+
| log_bin | ON |
| log_bin_basename | E:\wamp\bin\mysql\mysql5.6.12\data\mysql-bin |
| log_bin_index | E:\wamp\bin\mysql\mysql5.6.12\data\mysql-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| log_error | E:\wamp\logs\mysql.log |
| log_output | FILE |
| log_queries_not_using_indexes | OFF |
| log_slave_updates | OFF |
| log_slow_admin_statements | OFF |
| log_slow_slave_statements | OFF |
| log_throttle_queries_not_using_indexes | 0 |
| log_warnings | 1 |
+-------------------------------------+
6. Mysql數據庫服務所在主機安全配置
安全問題是一個綜合的縱深問題，Mysql的安全配置和所在系統(*iux、windows)的安全配置密切相關。
0×1: mysql進程運行賬號
所謂"mysql進程運行賬戶"，即以什麼樣的身份權限來啟動mysqld這個服務進程的。對於操作系統來說，每一個進程都有一個對應的"進程運行帳號"，這個進程運行帳號決定了這個應用程序可以獲得哪些操作系統的權限。
1. 在windows下禁止使用local system(nt authority\system)來運行mysql賬戶，可以考慮使用network service或者自己新建一個windows賬號，但是必須給與mysql程序所在目錄的讀取權限和data目錄的讀取和寫入權限
2. 在linux下，新建一個mysql賬號，並在安裝的時候就指定mysql以mysql賬戶來運行，給與程序所在目錄的讀取權限，data所在目錄的讀取和寫入權限。
0×2: mysql運行賬號的磁盤權限
對mysql運行帳號的磁盤權限的配置，就是在進行ACL的配置(文件夾右鍵->屬性->安全)，對於ACL的配置，我們需要牢記的是"默認禁止原則"，即操作系統會默認對沒有明確指示的權限設定為禁止，即假如你給一個用戶授予了某個文件夾的讀權限，那麼它只有讀權限，而不會擁有寫權限(權限繼承不考慮在內)。
對於mysql運行張厚啊的磁盤ACL配置，我們可以遵循以下原則
1. mysql運行賬號需要給予程序所在目錄的讀取權限，以及data目錄的讀取和寫入權限，保證mysql的正常運行
2. 不容許給予其他目錄的寫入和執行權限，特別是有網站的，這可以有效防御針對mysql的提權、或者webshell提權
1) udf提權
2) 系統關鍵目錄、注冊表寫入啟動文件
3. 取消mysql運行賬戶對於cmd，sh等一些程序的執行權限，這可以防御當mysql核心帳號被黑客獲取後進一步提權
1) root賬戶被洩露
由於對cmd、sh等關鍵程序進行了權限控制，黑客無法繼續深入操作系統提權
0×3: Chrooting
Chroot是Unix/類Unix的一種手段，它的建立會將其與主系統幾乎完全隔離，也就是說，一旦遭到什麼問題，也不會危及到正在運行的主系統。這是一個非常有效的辦法，特別是在配置網絡服務程序的時候。
0×4: 刪除歷史命令記錄
歷史命令記錄是一種測信道數據洩漏，從某種程序上來說，"歷史命令記錄"就像種植在系統上的一個鍵盤記錄rootkit，如果黑客獲取到了目標服務器的webshell，就可以通過閱讀"歷史命令記錄"來獲取到大量的管理員操作記錄，包括帳號和密碼。
這些歷史文件包括:
1. ~/.bash_history
2. ~/.mysql_history
..
cat /dev/null > ~/.bash_history
cat /dev/null > ~/.mysql_history
0×5: mysql.sock安全配置
默認情況下，PHP支持使用socket方式和msyql數據庫進行通信，換句話來說，這也意味著，在服務器本機可以允許無密碼直接登錄mysql，請看下面的一段實例
< ?php
ini_set("mysql.default_socket = /var/lib/mysql/mysql.sock");
$sql = "select user();";
$res = mysql_query($sql);
$final = mysql_fetch_array($res);
die(var_dump($final));
?>
執行成功，result:
array(2) { [0]=> string(16) "apache@localhost" ["user()"]=> string(16) "apache@localhost" }
這意味著黑客在獲取了目標服務器的webshell之後，可以在不知道mysql帳號密碼的情況下直接從數據庫中獲取隱私數據。
防御的方法還是一樣，針對mysql程序帳號進行磁盤ACL控制，防止mysql越權讀/寫/執行非mysql目錄下的文件。
7. 部署SQL注入檢測、防御模塊
根據OWASP2013的報告顯示，針對數據庫的攻擊方式，SQL注入依然是主要的因素，因此針對SQL Injection的攻擊，除了針對應用層的代碼安全審計、SDLC之外，在數據庫層部署數據庫防火牆也應該作為縱深防御的一個手段。
目前基於SQL注入檢測、防御的的數據庫防火牆大概有以下幾個:
1. 安華金和數據庫防火牆系統(Xsecure-DBFirewall)
2. Snort入侵檢測系統
能針對指定端口進行正則特征匹配方式的SQL注入檢測
3. Java/J2EE 過濾器
對於J2ee的WEB應用來說，可以在HTTP請求上部署過濾器，並將SQL注入檢測規律寫在過濾器中
4. druid-sql-wall開源SQL檢測、阻斷系統
8. mysqld安全相關啟動選項
1. --local-infile[={0|1}]
如果用–local-infile=0啟動服務器，則客戶端不能使用LOCAL in LOAD DATA語句，防止基於注入的直接文件讀取數據洩漏
2. --old-passwords
強制服務器為新密碼生成短(pre-4.1)密碼哈希。當服務器必須支持舊版本客戶端程序時，為了保證兼容性這很有用。
3. (OBSOLETE) –safe-show-database
1) 在MySQL 5.1以前版本的MySQL中，該選項使SHOW DATABASES語句只顯示用戶具有部分權限的數據庫名
2) 在MySQL 5.1中，該選項不再作為現在的 默認行為使用，有一個SHOW DATABASES權限可以用來控制每個賬戶對數據庫名的訪問。
4. --safe-user-create
如果啟用，用戶不能用GRANT語句創建新用戶，除非用戶有mysql.user表的INSERT權限。如果你想讓用戶具有授權權限來創建新用戶，你應給用戶授予下面的權限：
mysql> GRANT INSERT(user) ON mysql.user TO 'user_name'@'host_name’;這樣確保用戶不能直接更改權限列，必須使用GRANT語句給其它用戶授予該權限。
5. --secure-auth
不允許鑒定有舊(pre-4.1)密碼的賬戶。
6. --skip-grant-tables
這個選項導致服務器根本不使用權限系統。這給每個人以完全訪問所有的數據庫的權力，這個選項常常在發生了忘記了msyql密碼的情況使用這個方式在本機"無密碼登錄mysql"通過執行mysqladmin flush-privileges或mysqladmin eload命令，或執行FLUSH PRIVILEGES語句，你能告訴一個正在運行的服務器再次開始使用授權表。
7. --skip-name-resolve
主機名不被解析。所有在授權表的Host的列值必須是IP號或localhost
8. --skip-networking
在網絡上不允許TCP/IP連接。所有到mysqld的連接必須經由Unix套接字進行
9. --skip-show-database
使用該選項，只允許有SHOW DATABASES權限的用戶執行SHOW DATABASES語句，該語句顯示所有數據庫名。不使用該選項，允許所有用戶執行SHOW DATABASES，但只顯示用戶有SHOW DATABASES權限或部分數據庫權限的數據庫名。請注意全局權限指數據庫的權限。
9. mysql備份策略
像mysql、sqlserver、access這種數據庫都是將數據以單獨文件的形式保存在磁盤上的，所以，對於數據庫的備份也可以采用傳統的文件備份策略。總的來說，有以下方式:
1. 本地備份
使用mysqldump進行備份非常簡單，在備份數據庫的時候，我們還可以同時使用管道gzip命令對備份文件進行壓縮，可以采用Rsync的異地備份方式方式，將備份服務器的目錄掛載到數據庫服務器，將數據庫文件備份打包後，通過crontab定時備份數據：
備份數據使用命令：
#!/bin/sh
time=`date +"("%F")"%R`
$/usr/local/mysql/bin/mysqldump -u root -p111 database_backup | gzip > /home/zhenghan/mysql/mysql_backup.$time.gz
# crontab -l
# m h dom mon dow command00 00 * * * /home/zhenghan/mysql/backup.sh
恢復數據使用命令：
gzip -d mysql_backup.\(2014-06-17\)00\:00.gz
mysql_backup.(2014-06-17)00:00#mysql –u root -p111 < /home/zhenghan/mysql/mysql_backup.\(2014-06-17\)00\:00
2. 網絡備份
3. MySQL本身自帶的mysqldump備份
使用mysqldump可以把整個數據庫裝載到一個單獨的文本文件中。這個文件包含有所有重建您的數據庫所需要的SQL命令。這個命令取得所有的模式(schema)並且將其轉換成DDL語法(CREATE語句，即數據庫定義語句)，取得所有的數據，並且從這些數據中創建INSERT語句。這個工具將您的數據庫中所有的設計倒轉。因為所有的東西都被包含到了一個文本文件中。這個文本文件可以用一個簡單的批處理和一個合適SQL語句導回到MySQL中。
4. 直接復制數據庫文件的備份形式
直接拷貝數據文件最為直接、快速、方便，但缺點是基本上不能實現增量備份。為了保證數據的一致性，需要在備份文件前，執行以下SQL語句：FLUSH TABLES WITH READ LOCK；也就是把內存中的數據都刷新到磁盤中，同時鎖定數據表，以保證拷貝過程中不會有新的數據寫入。這種方法備份出來的數據恢復也很簡單，直接拷貝回原來的數據庫目錄下即可。
