mysql安全性系統是靈活的。它允許以許多不同的方法設置用戶訪問權限。通常，可通過grant 和revoke 語句來進行，這些語句對控制客戶機訪問的授權表進行修改。但是，您擁有的可能是不支持這些語句的舊版本mysql（這些語句在mysql3.22.11以前的版本 中沒有使用），或者可能發覺用戶的權限好像不是按希望地在工作。對于這樣的情況，了解mysql授權表的結構以及服務器怎樣使用它們來決定訪問許可權是有幫助的。您了解到這樣一個程度，就可以通過直接修改授權表來增加、刪除或修改用戶的權限，還可以在觳楸硎?br> 診斷權限的問題。 筆者假定您已經閱讀了第11章的“用戶賬號管理”一節，并理解grant 和r e v o k e語句是怎樣工作的。grant 和revoke 提供了建立mysql賬號和相關權限的便利方法，但是，它們只是一個前端。所有真正的操作都發生在mysql授權表中。
mysql授權表的結構和內容
在網絡上連接到服務器的客戶機對mysql數據庫的訪問是由授權表內容控制的。這些表定位在mysql數據庫中，并在首次安裝mysql的過程中進行初始化（如附錄a 所描述的）。表12-1和表12-2 示出列五個授權表，它們是user、db、host、tables_priv 和c o l um n s _ priv。 授權表的內容按下列各項使用： user user 表列出可連接到服務器和口令的用戶，并指定用戶擁有哪些全局（超級用戶）權限（如果有的話）。任何在user 表項中所允許的權限都是全局權限，并適用于所有的數據庫。例如，如果在這里允許delete 權限，則在該項中列出的用戶可從任何表中刪除記錄。因此，在進行這項操作之前千萬要小心，通常，最好在user 表項中關閉所有的權限，而使用其他的、有更多限制的表來指定權限。對超級用戶（如r o o t）則是一個例外，但一般很少有。 db db 表列出數據庫以及哪些用戶擁有訪問這些數據庫的權限。這里指定的權限適用于數據庫中所有的表。 host host 表與db表結合使用，在更細的級別上控制對特定主機的數據庫訪問權限。該表不受grant 和revoke 語句的影響，因此您會發現根本不會去使用它。 tables_priv tables_priv 表指定表級的權限。在這里所指定的權限適用于表中所有的列。 columns_priv columns_priv 表指定列級的權限。在這里所指定的權限適用于表中特定的列。 在12 . 2 . 4節“不用grant 建立用戶”中，我們將討論grant 語句怎樣修改這些表以及怎樣通過直接修改授權表來達到相同的結果。 tables_priv 和columns_priv 表是在mysql3.22.11中引入的（與grant 語句同時）。如果您擁有mysql的舊版本，則mysql數據庫只有user、db 和host 表。如果已經從舊版本升級到3 . 2 2 . 11以上的版本，但仍沒有tables_priv 和columns_priv 表的話，可運行mysql_fix_privileges_table 腳本創建它們。 沒有rows_priv 表，因為mysql不提供記錄級的權限。例如，不能使用戶只局限于某些列中包含某個值的表中的那些行。如果需要這個能力，必須編寫應用程序。如果要想執行咨詢記錄級鎖定（advisory record-level locking），可用附錄c 中介紹的get_lock() 函數進行。 授權表中包含兩種類型的列：作用域列（ scope column）和權限列（ privilege column），前者決定一個項何時可用，后者決定一個項可授予哪些權限（有些授權表中包含其他各式各樣的列，但在這里與我們無關）。 1. 授權表的作用域列 授權表作用域列指定表項何時使用。每個授權表項中都包含user 和host 列，以指明該項在特定的用戶從特定的主機上連接時應用（ host 表是一個例外，它被用于一種特定的、我們還未接觸過的方法中）。其他表中包含附加的作用域列。例如， db 表中包含一個db 列以指明該項適用于哪個數據庫。同樣， tables_priv 和columns_priv 表中包含使該作用域對數據庫中特定表或表中的列縮小的作用域字段。 2. 授權表權限列 授權表中還包含權限列。這些列指明了哪些權限被在作用域列中指定的用戶所擁有。mysql支持的權限顯示在以下列表中。該列表使用用于grant 語句的權限名。對于大部分來說，在user、db 和host 表中權限列的名字與在第11章利用grant 語句連接中所討論的 權限名顯然是相同的。例如， select_priv 列對應于select 權限。 3. 數據庫和表的權限 以下權限適用于數據庫和表的操作： alter 允許使用alter table 語句。這實際上是一個簡單的一級權限，您必須根據打算用該表做什么以擁有其他的權限。 create 允許創建數據庫和表。這個權限不允許您創建索引。 delete 允許從表中刪除已有記錄。 drop 允許刪除數據庫和表。不允許刪除索引。 index 允許創建或刪除表的索引。 insert 允許在表中插入新的記錄。 references 未使用。 select 允許用select 語句從表中檢索數據。該權限對于不含表的select 語句是不必要的，如select now() 或select 4/2。 update允許修改表中的已有記錄。 4. 管理權限 下列權限適用于控制服務器操作或用戶授權能力的管理操作： file 允許服務器在服務器主機上讀寫文件。該權限如果沒有正當的原因則不應授予,如12 . 2 . 3節“授權表應避免的風險”中所述，它是危險的。服務器采取某些預防措施限定該權限在特定范圍內使用。您只可以讀世人都可讀的文件，因此不需要考慮任何方式的保護。正在進行寫操作的文件不允許是已經存在的。這可防止服務器覆蓋重要的文件（如/ e t c / pass w d）或屬于其他用戶的數據庫文件。例如，如果不施加該約束，您可能會替換全部mysql數據庫中的授權表的內容。 如果您授予file 權限，就不能作為unix 的root 用戶運行服務器，因為root 能在文件系統的任何地方創建新的文件。如果作為未授權用戶運行服務器，則服務器只在該用戶可訪問到的目錄中創建文件。 grant 允許將您所擁有的權限授予其他用戶，其中包括grant 權限。 process 允許通過使用show processlist 語句或mysqladmin processlist 命令查詢有關正在服務器中運行的線程信息。該權限還允許利用kill 語句或mysqla d m i n kill 命令取消線程。您始終可以查看或取消自己的線程。process 權限授予您對任何線程進行這些操作的能力。 reload 允許執行多種服務器管理操作。可發布flush sql 語句，還可執行mysqladmin 的命令r e l o a d、r e f r e s h、f l us h - host s、f l us h - l o g s、flush-privileges 和f l us h - tables。 通常這不是有危險的權限，盡管它實際上是管理權限。 shutdown 允許利用mysqladmin shutdown 關閉服務器。 在user、db 和host 表中，每個權限都作為單獨的列給出。這些列都是用enum （“n”、“y”）類型聲明的，因此所有權限的缺省值為“n” （o ff）。tables_priv 和columns_priv 表的權限由set 語句表示，它允許權限以使用單個列的任何組合形式指定。這兩個表比其他三個表新，這就是為什么它們使用了更有效的表示方法的原因（user、db 和host 有可能在將來被改造，也通過set 來表示權限）。 table_priv 表的table_priv 列定義如下： set ('select ','insert','update','delete','create','drop','grant','references','index','alter') columns_priv 表的column_priv 列定義如下： set ('select ','insert','update','references') 列權限比表權限少得多，因為在列級中有意義的操作很少。例如，您可以創建一個表，但不能創建孤立的列。 user 表中包含對某些權限的列，這些權限不出現在任何其他授權表中，如f i l e _ priv、 p r o c e s s _ priv、reload_priv 和shutdown_priv 表。這些權限適用于執行與任何特定數據庫或與表無關的服務器的操作。例如，使用戶根據當前數據庫關閉服務器是無意義的。
服務器如何控制客戶機的訪問
在使用mysql時，客戶機訪問控制有兩個階段。第一階段發生在連接服務器時。服務器查找user 表看看是否能夠找到與您的名字、正在連接的主機以及所提供的口令相匹配的項。如果不匹配，則不能連接。若匹配，則建立連接，然后繼續進行第二階段。在此階段中，對于您發布的每個查詢，服務器都會檢查授權表以查看您是否具有充足的權限來執行該查詢。第二階段繼續，直到關于該服務器的會話結束為止。 本節詳細討論mysql用來將授權表項與輸入的客戶機連接請求和與查詢相匹配的規則。這包括在授權表作用域列中合法的值的類型、在授權表中權限信息組合的方法，以及表項檢查的次序。 1. 作用域列的內容 某些作用域列需要直接量，但大多數列允許通配符或其他特殊的值。 host 該列值可以是一個主機名或一個ip 號。localhost 值的含義是本地主機，但僅當您實際使用localhost 主機值而不是使用該主機名連接時才進行匹配。假定本地主機名為p i t - v i per. s n a k e . n e t，且在user 表中有兩個項，一個帶有host 值或localhost，而另一個帶有p i t - v i per.snake.net 值。帶有localhost 值的項僅當您連接到localhost 時才進行匹配。另一個項僅當您連接到p i t - v i per.snake.net 時才匹配。如果想讓用戶能夠以任意一種方式進行連接，在user 表中需要兩個項。還可以用通配符指定host 的值。sql的模式字符‘ %’和‘ _’也可以使用，并與查詢中的like 操作符有相同的含義。sql 模式（不允許regex 模式）字符可用于名字和ip 號。例如，%.wise.edu將與wise.edu域中的任何主機相配。同樣， 192.168.% 與192.168 類b 子網中的任何主機相配，因而192.168.3.% 與192.168.3 類c 子網中的任何主機相配。 值‘%’總是與任何主機相配，用于允許某個用戶從任何地方進行連接。空白的h o s t的值與‘%’含義相同（例外：在db 表中，空白的host 值含義是“檢查host 表的進一步的信息”。 自mysql3.23 以來，還可以利用表明網絡號的二進制位數的網絡掩碼指定ip 號。例如， 192.168.128.0/17 指定17 位的網絡號并用ip 地址的前17 位中的19 2 . 16 8 . 12 8與所有主機相配。 user 用戶名必須或者是直接量或者是空白的（空）。空白值與任何用戶相配。作為user 值的% 不意味著空白，相反，它與帶有% 的直接名字的用戶相配，這可能不是您想要的東西。 當一個輸入的連接對應user 表進行檢查并且相配的項包含一個空白的user 值時，客戶機被認為是匿名用戶。 password 口令值或者是空白的（空）或者是非空的，但不允許通配符。空白的口令并不是說與任何口令相配。它的意思是用戶不必指定口令。口令以加密值而不是以直接值被存儲。如果在password 列存儲了一個直接的口令，則該用戶將不能連接！grant 語句和mysqladmin password 命令自動對口令進行加密，但是，如果使用像insert、replace、update或set password 這樣的語句，則必須用pa s s w o r d (“n e w _ pa s s w o r d”) 而不是簡單地用“n e w _ pass w o r d” 來指定口令。 db 在columns_priv 和tables_priv 表中，db 值必須是直接的數據庫名，不允許模式和空白名。在dn 和host 表中，db 值可以用直接量指定，或通過使用指定通配符的sql 模式字符‘%’或‘_’來指定。% 值或空白將與任何數據庫相配。 ta b l e _ name、column_name 這些列中的值必須是直接量的表名或列名，模式值和空白是不允許的。 有些作用域列由服務器視為區分大小寫的，其他的則不是。這些規則已在表12 - 3中總結。特別注意， table_name 值始終是區分大小寫的，即使查詢中的表名處理是根據服務器運行的文件系統，其大小寫敏感性也是如此（在unix 中區分大小寫，而在windows 中不區分大小寫）。 2. 查詢訪問檢查 每當您發布查詢時，服務器都要檢查您是否有足夠的權限來執行查詢。它是通過依次檢查user、db、table_priv 和columns_priv 表來進行的，直到它確定您有適當的訪問權或徒然地搜索了所有的表為止。更準確地說： 1) 在開頭進行連接以查看所擁有的全局權限時，服務器檢查相匹配的user 表項。如果有全局權限且滿足該查詢，則服務器執行查詢。 2) 如果全局權限不滿足，則服務器在db 表中尋找一個項，并將該項的權限增加到您的全局權限中。若結果滿足該查詢，則服務器執行查詢。 3) 如果全局和數據庫級權限的組合不夠，服務器將保持不斷地查找，首先在tables _ priv 表中，然后在columns_priv 表中查找。 4) 如果在所有表檢查后發現您沒有許可權，服務器將拒絕執行查詢。 口令是怎樣存儲在user 表中的口令在user 表中以加密串的形式出現，因此您不知道用戶的口令是什么，即使已經擁有對該表的訪問權也是如此。通常，似乎認為pa s s w o r d（）函數執行與unix 口令所使用的類型相同的加密方法，其實并不是這樣的。 當兩種加密方法是單向的且不可逆時它們是相同的，但是， mysql不使用與unix 相同的加密算法。這意味著，即使您使用unix 口令作為mysql的口令，也別希望加密的口令串相配。如果想對應用程序使用unix 的加密方法，應使用c rypt() 函數而非pa s s w o r d ( )。 在邏輯條件下，授權表由服務器按以下形式使用： user or db or tables_priv or columns_priv 您可能正在奇怪，為什么上面的描述只涉及到五個授權表中的四個。正擊中要害，服務器實際檢查訪問許可權的方法如下： user or (db and host) or tables_priv or columns_priv 筆者先給出了較簡單的表達式，因為host 表不受grant 或revoke 語句的影響。如果一直保持使用grant 和revoke 來管理用戶權限，將不需要考慮host 表。但下面還是給出了對該表的討論，以便您有所了解： 當服務器檢查數據庫級的權限時，它查看客戶機的db 表的項。如果host 列值是空白，其含義是“檢查host 表查找哪些服務器可訪問該數據庫”。 服務器利用與來自db 表項相同的db 列為項查看host 表。如果host 表項與客戶機主機不相配，就不授予數據庫級權限。如果這些項都與客戶機正在連接的主機的host 列值相配，則db 表的項和host 表的項進行組合以產生客戶機的數據庫級權限。 但是，權限用邏輯and 進行組合，其意思是，除非客戶機同時出現在兩個項中，否則它沒有指定的權限。這樣，可以在此db 表項中授予一組基本的權限，然后用host表項有選擇地對特定的主機禁止使用這些權限。例如，允許從域的所有主機中訪問某個數據庫，但是對于定位在非安全范圍內的主機禁止使用數據庫權限。 以上描述無疑要進行訪問檢查，這聽起來好像是相當復雜的過程，尤其是考慮到服務器要為客戶機發布的每一個單獨的查詢檢查權限時。但是，該過程相當地快，因為服務器不對每個查詢實際檢查授權表的信息。相反，在服務器啟動時，它將該表的內容讀到內存中，然 后用內存中（i n - m e m o r y）的拷貝來檢驗查詢。這對于訪問檢查操作性能產生了推進，但有相當重要的負面效應：如果您直接修改了授權表的內容，則服務器將不會注意到權限的改變。 例如，如果通過用insert 語句增加一個新記錄到user 表中來增加了一個用戶，在該項中指定的該用戶將不能連接到該服務器。這是迷惑新管理員的問題（有時比較有經驗的管理員也是如此），但是解決方案很簡單：告訴服務器在您修改授權表后重新加載其內容即可。可以通過發布flush privileges 語句或通過執行mysqladmin flush-privileges （或mysqladmin reload，如果是不支持flush-privileges 的舊版本的話）來進行。 3. 作用域列匹配順序 mysql服務器以一種特定的方式對授權表的項進行排序，然后試著通過按順序查看所有的項來匹配輸入的連接。所發現的第一個匹配確定被使用的項。重要的是要理解mysql使用的排序順序，尤其是對于user 表的排序。這好象是在為難試圖理解mysql安全性的許多 人們。 當服務器讀取user 表的內容時，它根據host 和user 列的值對項進行排序。host 值是域值（帶有相同host 值的項被一起存放，然后按照user 值進行排序）。但是，排序不是詞典式的，或不完全是這樣的。要記住的原則是直接值比模式值優先。這意味著如果正從 boa.snake.net 中進行連接并且帶有boa.snake.net 和%.snake.net 的host 值，則直接值將是首選的。同樣， %.snake.net 優先于% . n e t，如此類推，%.net 優先于%。ip 號也以這種方法進行匹配。對于從帶有192.168.3.14 的ip 號的主機中連接的客戶機，具有19 2 . 16 8 . 3 . 4、19 2 . 16 8 . 3 . %、19 2 . 16 8 . %、192.% 和% 的host 值將按此順序匹配。
授權表應避免的風險
本節討論在授權時應遵守的某些預防措施以及維護人員作出輕率選擇所冒的風險。通常，給用戶授超級用戶權限應保守。也就是說，不要在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 權限的任何客戶機也都可通過網絡連接并讀取它們！下面的過程說明如何進行此項操作： 創建有longblob 列的表： use test create table tmp (b longblob) 用此表讀取您要竊取的表的每個文件的內容，然后將該表的內容寫到您自己的數據庫文件中： 現在，您有了一個新表y，它包含other_db.x 的內容，您可以對它進行完全訪問。 為了避免某人用同樣的方式攻擊您，應根據“內部安全性：安全數據目錄訪問”的指導設置數據目錄的許可權。當啟動服務器以限制用戶利用show database 和s h o w table s對他們不能訪問的數據庫進行訪問時，還可使用-skip-show-database 選項。這將有助于防止用戶查找不應訪問的數據庫和表。 alter 權限可能以您沒有設想的任何方法被使用。假定您要user1能訪問table1但不能訪問t a b l e 2。但帶有alter 權限的用戶可能會通過使用alter table 將table2 重新命名為table1來打亂您的這一設想。 要小心使用grant 權限。如果兩個用戶有不同的權限但都具有grant權限，則他們能使互相的訪問權更強大。
不用grant 建立用戶
如果是mysql3.22.11以前的版本，則不能用grant（或r e v o k e）語句建立用戶和訪問權限，但是可以直接修改授權表的內容。如果理解grant 語句是怎樣修改授權語句的，這個問題就很容易理解。可以通過手工發布insert 語句自己來進行（ insert 語句很難正確輸入，但這是另外的問題。事實上這個問題就是為什么grant 語句設計得如此易于使用的原因）。 當發布grant 語句時，指定了用戶名和主機號，可能還指定了口令。user 表項對該用戶建立，這些值記錄在該項的u ser、host 和password 列中。需要仔細考慮的一件事是，grant 語句對口令進行加密，而insert 則不能，它需要用password() 函數對insert語句中的口令進行加密。 如果已經指定了數據庫級的權限，用戶名和主機名將記錄在db 表項的user 和host 列中。已授權的數據庫記錄在db 列中，所授予的權限記錄在權限列中。 對于表級和列級權限，效果是類似的。在tables_priv 和columns_priv 表中創建項來記錄用戶名、主機名和數據庫以及需要的表或者表和列。授予的權限記錄在權限列中。 如果還記得上述討論，即使不用grant 語句也能夠進行grant 的工作。請記住，當直接修改授權表時，需要告訴服務器重新加載授權表，否則它將不會留意這些變化。可以通過執行mysqladmin flush-privileges 或mysqladmin reload 命令施加重新加載操作。如果忘記 這步操作，服務器將不按您的設想進行工作。 以下grant 語句創建有全部權限的超級用戶，其中包括向其他用戶授權的能力： grant all on *.* to [email protected] identfiedby "coffee" with grant option 該語句將創建user 表的[email protected] 的項，并開啟所有權限，因為超級（全局）用戶將存儲在那里。用insert 進行同樣工作的語句是： 這是一個很難看的insert 語句！您甚至會發現它在您的mysql版本上不工作。授權表的結構可能已經改變，在user 表中可能不會有14 個權限列。此時，應使用s h o w columns 來查找每個授權表包含些什么權限列，然后調整insert 語句。 下列grant 語句還創建具有超級用戶狀態的用戶，但是只對單個的權限： grant all on *.* to [email protected] identfiedby "flushpass" 您可能還記得我們曾在第11章建立flush 用戶時使用過該語句。本例中的insert 語句比前一個更簡單，可以很容易地列出列名并指定唯一的一個權限列。所有其他的列都將設置為缺省值“n”： 數據庫級的權限是用on db_name.* 子句而不是用on *.* 授予的： grant all on samp_db.* to [email protected] identfiedby "ruby" 這些權限都不是全局的，因此不能存儲在user 表中。我們仍需要在user 表中創建一個項（使得用戶可以連接），但我們還需要創建一個db 項來記錄數據庫級的權限： “n” 列是針對grant 權限的，對于在末尾帶with grant option 的數據庫級的grant 語句，應該將該列設置為“y”。 為了設置表級或列級權限，對tables_priv 或columns_priv 表使用insert 語句。當然，如果沒有grant 語句，也將沒有這些表，因為它們都是在同一時間出現在mysql版本中的。如果有這些表但由于某種原因想手工操縱它們，那么您不能使用單個的列使權限有效。您或者設置tables _ priv. table_priv 或者設置c o l um n s _ priv.column_priv 為一個set 值，該set 值由您允許的權限組成。例如，為了允許對某個表的select 和insert 權限，應在相對的tables_priv 項中設置table_priv 列為“select, insert” 值。 如果要想修改某個用戶的權限（該用戶的mysql賬號已經存在），應使用update而非insert。無論是增加還是取消權限都是這樣。為了刪除一個完整的用戶，使用delete 從該用戶所在的每個授權表中刪除其項。 如果要想避免發布查詢來直接修改授權表，應看一看與mysql分發包一起的mysqla c c e ss和mysql_setpermissions 腳本。 一個權限難題，第二部分 在第11章的“一個權限難題，第一部分”中，我們看到了一種授權情況，在這種情況中權限沒有預想的效果。我們來簡單地敘述一下問題，經常與新的mysql安裝一起出現的一個問題是管理員想要為用戶增加一項，使用戶們可從幾個主機中進行連接。這樣做最直接的方法是使用包含‘ %’通配符的主機名說明符，因此管理員用類似以下的語句創建一個用戶： grant all on samp_db.* to [email protected]%.snake.net identfiedby "cocoa" fred 碰巧有一個服務器主機的賬號，因此他試圖從這里進行連接： 為什么會這樣？為了繼續理解，您必須同時考慮mysql_install_db 是怎樣建立初始授權表和服務器怎樣使用user 表的項匹配客戶機連接的。當通過運行mysql_ i n s t a l l _ db對數據庫初始化時，它創建帶有如下host 和user 值的user 表的項： 前兩項通過指定localhost 或主機名允許r o o t連接到本地主機。后兩項允許來自本地主機的匿名連接。當為fred 增加此項時，則user 表將包含這些項： 當服務器啟動時，它讀取這些項并存儲它們（先主機，然后是主機的用戶），其順序是比較詳細的值在前，不詳細的在后： 帶localhost 的兩項一起存儲，有root 的那個項放在前，因為這項比空白的更具體、更詳細。帶有p i t - v i per.snake.net 的項以類似的方法一起存儲。這些項都是不帶任何通配符的直接host 值，因此它們都優先于fred 的項進行存儲，而fred 項使用了一個通配符。特別地，匿名用戶項在存儲順序上優先于fred 的項。 此結果是，當fred 試圖從本地主機上進行連接時，帶有空白用戶名的項匹配先于在host 列中包含%.snake.net 的項。該項的口令是空白的，因為缺省的匿名用戶沒有口令。由于fred 在連接時指定了口令，則產生一個錯誤匹配和錯誤連接。 這里要記住的事情是，盡管使用通配符指定用戶可連接的主機這種方式非常方便，但只要您在user 表中保留匿名用戶，就可能會出現從本地主機中連接的問題。 通常，筆者建議刪除匿名用戶項。這將使您的工作更輕松一些： mysql> delete from user where user=""; 如果想更徹底的話，可將其他授權表的匿名用戶項也刪除。有user 列的表是db、tables_priv 和c o l um n s _ priv。 本節給出的難題是一種特殊的情況，但包含了更為普遍的內容。如果某個用戶的權限不按所希望的方式工作，則檢查授權表，看看是否有某些項包含了比所討論的該用戶的項更詳細的host 值，以及試圖通過那個用戶匹配連接的host 值。如果是這樣的，問題的原因可能就是它。您可能需要使該用戶的項更詳細（或增加另一個項來包括更詳細的情況）。
