本文主要考慮下列安全性有關的問題： MySQL管理員有責任保證數據庫內容的安全性，使得這些數據記錄只能被那些正確授權的用戶訪問，這涉及到數據庫系統的內部安全性和外部安全性。

內部安全性關心的是文件系統級的問題，即，防止MySQL數據目錄（DATADIR）被在服務器主機有賬號的人（合法或竊取的）進行攻擊。如果數據目錄內容的權限過分授予，使得每個人均能簡單地替代對應于那些數據庫表的文件，那么確保控制客戶通過網絡訪問的授權表設置正確，對此毫無意義。

外部安全性關心的是從外部通過網絡連接服務器的客戶的問題，即，保護MySQL服務器免受來自通過網絡對服務器的連接的攻擊。你必須設置MySQL授權表（grant table），使得他們不允許訪問服務器管理的數據庫內容，除非提供有效的用戶名和口令。

下面就詳細介紹如何設置文件系統和授權表mysql，實現MySQL的兩級安全性。

一、內部安全性-保證數據目錄訪問的安全

MySQL服務器通過在MySQL數據庫中的授權表提供了一個靈活的權限系統。你可以設置這些表的內容，允許或拒絕客戶對數據庫的訪問，這提供了你防止未授權的網絡訪問對你數據庫攻擊的安全手段，然而如果主機上其他用戶能直接訪問數據目錄內容，建立對通過網絡訪問數據庫的良好安全性對你毫無幫助，除非你知道你是登錄MySQL服務器運行主機的唯一用戶，否則你需要關心在這臺機器上的其他用戶獲得對數據目錄的訪問的可能性。

以下是你應該保護的內容：

顯然，你不想讓服務器主機上的其他用戶有數據庫目錄文件的寫權限，因為他們可以重寫你的狀態文件或數據庫表文件，但是讀權限也很危險。如果一個數據庫表文件能被讀取，偷取文件并得到MySQL本身，以普通文本顯示表的內容也很麻煩，為什么？因為你要做下列事情：

在考慮一下，從相反的角度，你想讓別人對你這樣嗎？當然不！你可以通過在數據庫錄下執行ls -l命令確定你的數據庫是否包含不安全的文件和目錄。查找有“組”和“其他用戶”權限設置的文件和目錄。下面是一個不安全數據目錄的一部分列出：

正如你看到的，有些數據庫有正確的權限，而其他不是。本例的情形是經過一段時間后的結果。較少限制的權限由在權限設置方面比更新版本更不嚴格的較早版本服務器設置的（注意更具限制的目錄menageria和tmp都有較近日期）。MySQL當前版本確保這些文件只能由運行服務器的用戶讀取。

讓我們來修正這些權限，使得只用服務器用戶可訪問它們。你的主要保護工具來自于由UNIX文件系統本身提供的設置文件和目錄屬主和模式的工具。下面是我們要做的：

在完成這些設置后，你最終應該得到下面的數據目錄權限：

二、外部安全性-保證網絡訪問的安全

MySQL的安全系統是很靈活的，它允許你以多種不同方式設置用戶權限。一般地，你可使用標準的SQL語句GRANT和REVOKE語句做，他們為你修改控制客戶訪問的授權表，然而，你可能由一個不支持這些語句的老版本的MySQL（在3.22.11之前這些語句不起作用），或者你發覺用戶權限看起來不是以你想要的方式工作。對于這種情況，了解MySQL授權表的結構和服務器如何利用它們決定訪問權限是有幫助的，這樣的了解允許你通過直接修改授權表增加、刪除或修改用戶權限，它也允許你在檢查這些表時診斷權限問題。

關于如何管理用戶賬號，見《MySQL的用戶管理》。而對GRANT和REVOKE語句詳細描述，見《MySQL參考手冊》。

2.1 MySQL授權表的結構和內容

通過網絡連接服務器的客戶對MySQL數據庫的訪問由授權表內容來控制。這些表位于mysql數據庫中，并在第一次安裝MySQL的過程中初始化（運行mysql_install_db腳本）。授權表共有5個表：user、db、host、tables_priv和columns_priv。

授權表的內容有如下用途：

在“不用GRANT設置用戶”一節里，我們再討論GRANT語句如何對修改這些表起作用，和你怎樣能通過直接修改授權表達到同樣的效果。

tables_priv和columns_priv表在MySQL 3.22.11版引進（與GRANT語句同時）。如果你有較早版本的MySQL，你的mysql數據庫將只有user、db和host表。如果你從老版本升級到3.22.11或更新，而沒有tables_priv和columns_priv表，運行mysql_fix_privileges_tables腳本創建它們。

MySQL沒有rows_priv表，因為它不提供記錄級權限，例如，你不能限制用戶于表中包含特定列值的行。如果你確實需要這種能力，你必須用應用編程來提供。如果你想執行建議的記錄級鎖定，你可用GET_LOCK()函數做到。

授權表包含兩種列：決定一個權限何時運用的范圍列和決定授予哪種權限的權限列。

2.1.1 授權表范圍列

授權表范圍列指定表中的權限何時運用。每個授權表條目包含User和Host列來指定權限何時運用于一個給定用戶從給定主機的連接。其他表包含附加的范圍列，如db表包含一個Db列指出權限運用于哪個數據庫。類似地，tables_priv和columns_priv表包含范圍字段，縮小范圍到一個數據庫中的特定表或一個表的特定列。

2.1.2 授權表權限列

授權表還包含權限列，他們指出在范圍列中指定的用戶擁有何種權限。由MySQL支持的權限如下表所示。該表使用GRANT語句的權限名稱。對于絕大多數在user、db和host表中的權限列的名稱與GRANT語句中有明顯的聯系。如Select_priv對應于SELECT權限。

2.1.3 數據庫和表權限

下列權限運用于數據庫和表上的操作。

2.1.4 管理權限

下列權限運用于控制服務器或用戶授權能力的操作的管理性操作。

在user、db和host表中，每一個權限以一個單獨的列指定。這些列全部聲明為一個ENUM(\"N\",\"Y\")類型，所以每個權的缺省值是“N”。在tables_priv和columns_priv中的權限以一個SET表示，它允許權限用一個單個列以任何組合指定。這兩個表比其他三個表更新，這就是為什么它們使用更有效的表示方式的原因。（有可能在未來，user、db和host表也用一個SET類型表示。）

在tables_priv表中的Table_priv列被定義成：

SET(\'Select\',\'Insert\',\'Update\',\'Delete\',\'Create\',\'Drop\',\'Grant\',\'References\',\'Index\',\'Alter\')

在coloums_priv表中的Column_priv列被定義成：　

SET(\'Select\',\'Insert\',\'Update\',\'References\')

列權限比表權限少，因為列級較少的權限有意義。例如你能創建一個表，但你不能創建一個孤立的列。

user表包含某些在其他授權表不存在的權限的列：File_priv、Process_priv、Reload_priv和Shutdown_priv。這些權限運用于你讓服務器執行的與任何特定數據庫或表不相關的操作。如允許一個用戶根據當前數據庫是什么來關閉數據庫是毫無意義的。

2.2 服務器如何控制客戶訪問

在你使用MySQL時，客戶訪問控制有兩個階段。第一階段發生在你試圖連接服務器時。服務器查找user表看它是否能找到一個條目匹配你的名字、你正在從那兒連接的主機和你提供的口令。如果沒有匹配，你就不能連接。如果有一個匹配，建立連接并繼續第二階段。在這個階段，對于每一個你發出的查詢，服務器檢查授權表看你是否有足夠的權限執行查詢，第二階段持續到你與服務器對話的結束。

本小節詳細介紹MySQL服務器用于將授權表條目匹配到來的連接請求或查詢的原則，這包括在授權表范圍列中合法的值的類型、結合授權表中的權限信息的方式和表中條目被檢查的次序。

2.2.1 范圍列內容

一些范圍列要求文字值，但它們大多數允許通配符或其他特殊值。

2.2.2 查詢訪問驗證

每次你發出一個查詢，服務器檢查你是否有足夠的權限執行它，它以user、db、tables_priv和columns_priv的順序檢查，知道它確定你有適當的訪問權限或已搜索所有表而一無所獲。更具體的說：

用布爾運算的術語，授權表中的權限被服務器這樣使用：

user OR tables_priv OR columns_priv

你可能疑惑為什么前面的描述只引用4個授權表，而實際上有5個。實際上服務器是這樣檢查訪問權限：

user OR (db AND host) OR tables_priv OR columns_priv

第一個較簡單的表達式是因為host表不受GRANT和REVOKE語句影響。如果你總是用GRANT和REVOKE管理用戶權限，你絕不需要考慮host表。但是其工作原理你用該知道：

前面的描述毫無疑問使訪問檢查聽起來一個相當復雜的過程，特別是你以為服務器對你發出的每個查詢進行權限檢查，然而此過程是很快的，因為服務器其實不從授權表對每個查詢查找信息，相反，它在啟動時將表的內容讀入內存，然后驗證查詢用的是內存中的副本。這大大提高了訪問檢查操作的性能。但有一個非常明顯的副作用。如果你直接修改授權表的內容，服務器將不知道權限的改變。

例如，如果你用一條INSERT語句向user表加入一個新記錄來增加一個新用戶，命名在記錄中的用戶將不能連接服務器。這對管理員新手（有時對有經驗的老手）是很困惑的事情，當時解決方法很簡單：在你改變了它們之后告訴服務器重載授權表內容，你可以發一條FLUSH PRIVILEGES或執行mysqladmin flush-privileges（或如果你有一個不支持flush-privileges的老版本，用mysqladmin reload。）。

2.2.3 范圍列匹配順序

MySQL服務器按一種特定方式排序符授權表中的記錄，然后通過按序瀏覽記錄匹配到來的連接。找到的第一個匹配決定了被使用的記錄。理解MySQL使用的排序順序很重要，特別是對user表。

當服務器讀取user表內容時，它根據在Host和User列中的值排序記錄，Host值起決定作用（相同的Host值排在一起，然后再根據User值排序）。然而，排序不是典序（按詞排序），它只是部分是。要牢記的是字面上的詞優先于模式。這意味著如果你正從client.your.net連接服務器而Host有client.your.net和%.your.net兩個值，則第一個先選。類似地，%.your.net優先于%.net，然后是%。IP地址的匹配也是這樣的。

總之一句話，越具體越優先。可以參見本文附錄的實例。

2.3 避免授權表風險

本屆介紹一些在你授權時的一些預防措施，以及不明值的選擇帶來的風險。一般地，你要很“吝嗇”地授予超級用戶權限，即不要啟用user表中條目中的權限，而使用其它授權表，以將用戶權限限制于數據庫、表、或列。在user表中的權限允許于影響到你的服務器操作或能訪問任何數據庫中的任何表。

不要授予對mysql數據庫的權限。一個擁有包含授權表數據庫權限的用戶可能會修改表以獲取對其他任何數據庫的權限。授予允許一個用戶修改mysql數據庫表的權限也實際上給了用戶以一個全局GRANT權限。如果用戶能直接修改表，這也等價于能夠發出任何你能想象的任何GRANT語句。

FILE權限尤其危險，不要輕易授權它。以下是一個擁有FILE權限的人能干除的事情：

    CREATE TABLE etc_passwd (pwd_entry TEXT);
    LOAD DATA INFILE \"/etc/passwd\" into TABLE etc_passwd;
    SELECT * FROM etc_passwd;

在發出這些語句后，用戶已經擁有了你的口令文件的內容了。實際上，服務器上任何公開可讀文件的內容都可被擁有FILE權限的用戶通過網絡訪問。

FILE權限也能被利用來危害沒有設置足夠權限制的文件權限的系統上的數據庫。這就是你為什么應該設置數據目錄只能由服務器讀取的原因。如果對應于數據庫表的文件可被任何人讀取，不只是用戶服務器賬號的用戶可讀，任何有FILE權限的用戶也可通過網絡連接并讀取它們。下面演示這個過程：

為避免讓人以同樣的方式攻擊，根據“第一部分 內部安全性-保護你的數據目錄”中的指令設置你的數據目錄上的權限。你也可以在你啟動服務器時使用--skip-show-database選項限制用戶對于他們沒用訪問權限的數據庫使用SHOW DATABASES和SHOW TABLES。這有助于防止用戶找到關于它們不能訪問的數據庫和表的信息。

ALTER權限能以不希望的方式使用。假定你想讓user1可以訪問table1但不能訪問tables2。一個擁有ALTER權限的用戶可以通過使用ALTER TABLE將table2改名為table1來偷梁換柱。

當心GRANT權限。兩個由不同權限但都有GRANT權限的用戶可以使彼此的權利更強大。

2.4 不用GRANT設置用戶

如果你有一個早于3.22.11的MySQL版本，你不能使用GRANT（或REVOKE）語句設置用戶及其訪問權限，但你可以直接修改授權表的內容。如果你理解GRANT語句如何修改授權表，這很容易。那么你通過手工發出INSERT語句就能自己做同樣的事情。

當你發出一條GRANT語句時，你指定一個用戶名和主機名，可能還有口令。對該用戶生成一個user表記錄，并且這些值記錄在User、Host和Password列中。如果你在GRANT語句中指定全局權限，這些權限記錄在記錄的權限列中。其中要留神的是GRANT語句為你加密口令，而INSERT不是，你需要在INSERT中使用PASSWORD()函數加密口令。
如果你指定數據庫級權限，用戶名和主機名被記錄在db表的User和Host列。你為其授權的數據庫記錄在Db列中，你授予的權限記錄在權限列中。

對于表級和列級權限，效果是類似的。在tables_priv和columns_priv表中創建記錄以記錄用戶名、主機名和數據庫，還有相關的表和列。授予的權限記錄在權限列中。

如果你還記得前面的介紹，你應該能即使不用GRANT語句也能做GRANT做的事情。記住在你直接修改授權表時，你將通知服務器重載授權表，否則他不知道你的改變。你可以執行一個mysqladmin flush-privileges或mysqladmin reload命令強迫一個重載。如果你忘記做這個，你會疑惑為什么服務器不做你想做的事情。

下列GRANT語句創建一個擁有所有權的超級用戶。包括授權給別人的能力：

GRANT ALL ON *.* TO anyname@localhost IDENTIFIED BY \"passwd\"
    WITH GRANT OPTION

該語句將在user表中為anyname@localhost創建一個記錄，打開所有權限，因為這里是超級用戶（全局）權限存儲的地方，要用INSERT語句做同樣的事情，語句是：

INSERT INTO user  VALUES(\"localhost\",\"anyname\",PASSWORD(\"passwd\"),
    \"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\")

你可能發現它不工作，這要看你的MySQL版本。授權表的結構已經改變而且你在你的user表可能沒有14個權限列。用SHOW COLUMNS找出你的授權表包含的每個權限列，相應地調整你的INSERT語句。 下列GRANT語句也創建一個擁有超級用戶身份的用戶，但是只有一個單個的權限：

GRANT RELOAD ON *.* TO flush@localhost IDENTIFIED BY \"flushpass\"

本例的INSERT語句比前一個簡單，它很容易列出列名并只指定一個權限列。所有其它列將設置為缺省的\"N\"：

INSERT INTO user (Host,Password,Reload) VALUES(\"localhost\",\"flush\",PASSWORD(\"flushpass\"),\"Y\")

數據庫級權限用一個ON db_name.*子句而不是ON *.*進行授權：

GRANT ALL ON sample.* TO boris@localhost IDENTIFIED BY \"ruby\"

這些權限不是全局的，所以它們不存儲在user表中，我們仍然需要在user表中創建一條記錄（使得用戶能連接），但我們也需要創建一個db表記錄記錄數據庫集權限：

INSERT INTO user (Host,User,Password) VALUES(\"localhost\",\"boris\",PASSWORD(\"ruby\"))

INSERT INTO db VALUES(\"localhost\",\"sample_db\",\"boris\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"Y\",\"N\",\"Y\",\"Y\",\"Y\")

\"N\"列是為GRANT權限；對末尾的一個數據庫級具有WITH GRANT OPTION的GRANT語句，你要設置該列為\"Y\"。

要設置表級或列級權限，你對tables_priv或columns_priv使用INSERT語句。當然，如果你沒有GRANT語句，你將沒有這些表，因為它們在MySQL中同時出現。如果你確實有這些表并且為了某些原因想要手工操作它們，要知道你不能用單獨的列啟用權限。

你設置tables_priv.Table_priv或columns_priv.Column_priv列來設置包含你想啟用的權限值。例如，要對一個表啟用SELECT和INSERT權限，你要在相關的tables_priv的記錄中設置Table_priv為\"Select,Insert\"。

如果你想對一個擁有MySQL賬號的用戶修改權限，使用UPDATE而不是INSERT，不管你增加或撤銷權限都是這樣。要完全刪除一個用戶，從用戶使用的每個表中刪除記錄。

如果你愿意避免發一個查詢來直接修改全權表，你可以看一下MySQL自帶的mysqlaccess和mysql_setpermissions腳本。

附錄1 小測驗

在你剛剛新安裝了一個MySQL服務器，在你增加了一個允許連接MySQL的用戶，用下列語句：

GRANT ALL ON samp_db.* TO fred@*.snake.net IDENTIFIED \"cocoa\"

而fred碰巧在服務器主機上有個賬號，所以他試圖連接服務器：

%mysql -u fred -pcocoa samp_db
ERROR 1045: Access denied for user: \'fred@localhost\' (Using password: YES)

為什么？

原因是：

先考慮一下mysql_install_db如何建立初始權限表和服務器如何使用user表記錄匹配客戶連接。在你用mysql_install_db初始化你的數據庫時，它創建類似這樣的user表：

頭兩個記錄允許root指定localhost或主機名連接本地服務器，后兩個允許匿名用戶從本地連接。當增加fred用戶后，

在服務器啟動時，它讀取記錄并排序它們（首先按主機，然后按主機上的用戶），越具體越排在前面：

有localhost的兩個記錄排在一起，而對root的記錄排在第一，因為它比空值更具體。pit.snake.net的記錄也類似。所有這些均是沒有任何通配符的字面上的Host值，所以它們排在對fred記錄的前面，特別是匿名用戶排在fred之前。

結果是在fred試圖從localhost連接時，Host列中的一個空用戶名的記錄在包含%.snake.net的記錄前匹配。該記錄的口令是空的，因為缺省的匿名用戶沒有口令。因為在fred連接時指定了一個口令，由一個錯配且連接失敗。

這里要記住的是，雖然用通配符指定用戶可以從其連接的主機是很方便。但你從本地主機連接時會有問題，只要你在table表中保留匿名用戶記錄。

一般地，建議你刪除匿名用戶記錄：

mysql> DELETE FROM user WHERE User=\"\";

更進一步，同時刪除其他授權表中的任何匿名用戶，有User列的表有db、tables_priv和columns_priv。

附錄2 使一個新的MySQL安裝更安全

在你自己安裝了一個新的MySQL服務器后，你需要為MySQL的root用戶指定一個目錄（缺省無口令），否則如果你忘記這點，你將你的MySQL處于極不安全的狀態（至少在一段時間內）。

在Unix（Linux）上，在按照手冊的指令安裝好MySQL后，你必須運行mysql_install_db腳本建立包含授權表的mysql數據庫和初始權限。在Windows上，運行分發中的Setup程序初始化數據目錄和mysql數據庫。假定服務器也在運行。

當你第一次在機器上安裝MySQL時，mysql數據庫中的授權表是這樣初始化的：

從本地主機多服務器的連接是允許的，不管連接的用戶使用一個localhost主機名或真實主機名。如：

% mysql -h localhost test

% mysql -h pit.snake.net test

你以root連接MySQL甚至不指定口令的事實只是意味著初始安裝不安全，所以作為管理員的你首先要做的應該是設置root口令，然后根據你設置口令使用的方法，你也可以告訴服務器重載授權表是它知道這個改變。（在服務器啟動時，它重載表到內存中而可能不知道你已經修改了它們。）

對MySQL 3.22和以上版本，你可以用mysqladmin設置口令：

% mysqladmin -u root password yourpassword

對于MySQL的任何版本，你可以用mysql程序并直接修改mysql數據庫中的user授權表：

% mysql -u root mysql
mysql>UPDATE user SET password=PASSWORD(\"yourpassword\") WHERE User=\"root\";

如果你有MySQL的老版本，使用mysql和UPDATE。

在你設置完口令后，通過運行下列命令檢查你是否需要告訴服務器重載授權表：

% mysqladmin -u root status

如果服務器仍然讓你以root而不指定口令而連接服務器，重載授權表：

% mysqladmin -u root reload

在你設置了root的口令后（并且如果需要重載了授權表），你將需要在任何時候以root連接服務器時指定口令。