權限系統工作原理 MySQL權限系統保證所有的用戶可以嚴格地做他們假定被允許做的事情。當你連接一個MySQL服務器時， 你的身份由你從那連接的主機和你指定的用戶名來決定，系統根據你的身份和你想做什麼來授予權限。 MySQL在認定身份中考慮你的主機名和用戶名字，是因為有很小的原因假定一個給定的用戶在因特網上屬於同一個人。例如，用戶從whitehouse.gov連接的bill不必和從mosoft.com連接bill是同一個人。 MySQL通過允許你區分在不同的主機上碰巧有同樣名字用戶來處理它：你可以對從whitehouse.gov連接授與bill一個權限集，而為從microsoft.com的連接授予一個不同的權限集。 MySQL存取控制包含2個階段： 階段1：服務器檢查你是否允許連接。 階段2：假定你能連接，服務器檢查你發出的每個請求。看你是否有足夠的權限實施它。例如，如果你從數據庫中一個表精選(select)行或從數據庫拋棄一個表，服務器確定你對表有select權限或對數據庫有drop權限。 服務器在存取控制的兩個階段使用在mysql的數據庫中的user、db和host表，在這些授權表中字段如下： 表名稱 user db host 范圍字段 Host Host Host User Db Db Password User 權限字段 Select_priv Select_priv Select_priv Insert_priv Insert_priv Insert_priv Update_priv Update_priv Update_priv Delete_priv Delete_priv Delete_priv Index_priv Index_priv Index_priv Alter_priv Alter_priv Alter_priv Create_priv Create_priv Create_priv Drop_priv Drop_priv Drop_priv Grant_priv Grant_priv Grant_priv Reload_priv Shutdown_priv Process_priv File_priv 對存取控制的第二階段(請求證實)，如果請求涉及表，服務器可以另外參考tables_priv和columns_priv表。這些表的字段如下： 表名稱 tables_priv columns_priv 范圍字段 Host Host Db Db User User Table_name Table_name Column_name 權限字段 Table_priv Column_priv Column_priv 其他字段 Timestamp Timestamp Grantor 每個授權表包含范圍字段和權限字段。 范圍字段決定表中每個條目的范圍，即，條目適用的上下文。例如, 一個user表條目的Host和User值為thomas.loc.gov和bob將被用於證實來自主機thomas.loc.gov的bob對服務器的連接。同樣，一個db表條目的Host、User和Db字段的值是thomas.loc.gov、bob和reports將用在bob從主機聯接thomas.loc.gov存取reports數據庫的時候。 tables_priv和columns_priv表包含范圍字段，指出每個條目適用的表或表／列的組合。 對於檢查存取的用途，比較Host值是忽略大小寫的。User、Password、Db和Table_name值是區分大小寫的。Column_name值在MySQL3.22.12或以後版本是忽略大小寫的。 權限字段指出由一個表條目授予的權限，即，可實施什麼操作。服務器組合各種的授權表的信息形成一個用戶權限的完整描述。為此使用的規則在6.8 存取控制, 階段2：請求證實描述。 范圍字段是字符串，如下所述；每個字段的缺省值是空字符串： 字段名 類型 Host CHAR(60) User CHAR(16) Password CHAR(16) Db CHAR(64) (tables_priv和columns_priv表為CHAR(60)） 在user、db和host表中，所有權限字段被聲明為ENUM(N,Y)--每一個都可有值N或Y，並且缺省值是N. 在tables_priv和columns_priv表中，權限字段被聲明為SET字段： 表名 字段名 可能的集合成員 tables_priv Table_priv Select, Insert, Update, Delete, Create, Drop, Grant, References, Index, Alter tables_priv Column_priv Select, Insert, Update, References columns_priv Column_priv Select, Insert, Update, References 簡單地說，服務器使用這樣的授權表： user表范圍字段決定是否允許或拒絕到來的連接。對於允許的連接，權限字段指出用戶的全局(超級用戶)權限。 db和host表一起使用： db表范圍字段決定用戶能從哪個主機存取哪個數據庫。權限字段決定允許哪個操作。 當你想要一個給定的db條目應用於若干主機時，host表作為db表的擴展被使用。例如，如果你想要一個用戶能在你的網絡從若干主機使用一個數據庫，在用戶的db表的Host條目設為空值，然後將那些主機的每一個移入host表。這個機制詳細描述在6.8 存取控制, 階段2：請求證實。 tables_priv和columns_priv表類似於db表，但是更精致：他們在表和列級應用而非在數據庫級。 注意管理權限(reload, shutdown, 等等)僅在user表中被指定。這是因為管理性操作是服務器本身的操作並且不是特定數據庫，因此沒有理由在其他授權表中列出這樣的權限。事實上，只需要請教user表來決定你是否執行一個管理操作。 file權限也僅在user表中指定。它不是管理性權限，但你讀或謝在服務器主機上的文件的的能力獨立於你正在存取的數據庫。 當mysqld服務器啟動時，讀取一次授權表內容。對授權表的更改生效在6.9 權限更改何時生效描述。 當你修改授權表的內容時，確保你按你想要的方式更改權限設置是一個好主意。為幫助診斷問題，見6.13 “存取拒絕引起”錯誤的原因。對於安全問題上的忠告，見6.14 怎麼對使MySQL安全對抗解密高手。 一個有用的診斷工具是mysqlaccess腳本，由Carlier Yves 提供給MySQL分發。使用--help選項調用mysqlaccess查明它怎樣工作。注意：mysqlaccess僅用user、db和host表僅檢查存取。它不檢查表或列級權限。 6.7 存取控制, 階段1：連接證實 當你試圖聯接一個MySQL服務器時，服務器基於你的身份和你是否能通過供應正確的口令驗證身份來接受或拒絕連接。如果不是，服務器完全具結你的存取，否則，服務器接受連接，然後進入階段2並且等待請求。 你的身份基於2個信息： 你從那個主機連接 你的MySQL用戶名 身份檢查使用3個user表(Host, User和Password)范圍字段執行。服務器只有在一個user表條目匹配你的主機名和用戶名並且你提供了正確的口令時才接受連接。 在user表范圍字段可以如下被指定： 一個Host值可以是主機名或一個IP數字，或localhost指出本地主機。 你可以在Host字段裡使用通配符字符“%”和“_”。 一個Host值%匹配任何主機名，一個空白Host值等價於%。注意這些值匹配能創建一個連接到你的服務器的任何主機！ 通配符字符在User字段中不允許，但是你能指定空白的值，它匹配任何名字。如果user表匹配到來的連接的條目有一個空白的用戶名，用戶被認為是匿名用戶(沒有名字的用戶)，而非客戶實際指定的名字。這意味著一個空白的用戶名被用於在連接期間的進一步的存取檢查(即，在階段2期間)。 Password字段可以是空白的。這不意味著匹配任何口令，它意味著用戶必須不指定一個口令進行連接。 非空白Password值代表加密的口令。 MySQL不以任何人可以看的純文本格式存儲口令，相反，正在試圖聯接的一個用戶提供的口令被加密(使用PASSWORD()函數)，並且與存儲了user表中的已經加密的版本比較。如果他們匹配，口令是正確的。 下面的例子顯示出各種user表中Host和User條目的值的組合如何應用於到來的連接： Host 值 User 值 被條目匹配的連接 thomas.loc.gov fred fred, 從thomas.loc.gov 連接 thomas.loc.gov 任何用戶, 從thomas.loc.gov連接 % fred fred, 從任何主機連接 % 任何用戶, 從任何主機連接 %.loc.gov fred fred, 從在loc.gov域的任何主機連接 x.y.% fred fred, 從x.y.net、x.y.com,x.y.edu等聯接。（這或許無用） 144.155.166.177 fred fred, 從有144.155.166.177 IP 地址的主機連接 144.155.166.% fred fred, 從144.155.166 C類子網的任何主機連接 既然你能在Host字段使用IP通配符值(例如，144.155.166.%匹配在一個子網上的每台主機)，有可能某人可能企圖探究這種能力，通過命名一台主機為144.155.166.somewhere.com。為了阻止這樣的企圖，MySQL不允許匹配以數字和一個點起始的主機名，這樣，如果你用一個命名為類似1.2.foo.com的主機，它的名字決不會匹配授權表中Host列。只有一個IP數字能匹配IP通配符值。 一個到來的連接可以被在user表中的超過一個條目匹配。例如，一個由fred從thomas.loc.gov的連接匹配多個條目如上所述。如果超過一個匹配，服務器怎麼選擇使用哪個條目呢？服務器在啟動時讀入user表後通過排序來解決這個問題，然後當一個用戶試圖連接時，以排序的順序浏覽條目，第一個匹配的條目被使用。 user表排序工作如下，假定user表看起來像這樣： +-----------+----------+- | Host | User | ... +-----------+----------+- | % | root | ... | % | jeffrey | ... | localhost | root | ... | localhost | | ... +-----------+----------+- 當服務器在表中讀取時，它以最特定的Host值為先的次序排列(%在Host列裡意味著“任何主機”並且是最不特定的)。有相同Host值的條目以最特定的User值為先的次序排列(一個空白User值意味著“任何用戶”並且是最不特定的)。最終排序的user表看起來像這樣： +-----------+----------+- | Host | User | ... +-----------+----------+- | localhost | root | ... | localhost | | ... | % | jeffrey | ... | % | root | ... +-----------+----------+- 當一個連接被嘗試時，服務器浏覽排序的條目並使用找到的第一個匹配。對於由jeffrey從localhost的一個連接，在Host列的localhost條目首先匹配。那些有空白用戶名的條目匹配連接的主機名和用戶名。（%/jeffrey條目也將匹配，但是它不是在表中的第一匹配。） 這是另外一個例子。假定user桌子看起來像這樣： +----------------+----------+- | Host | User | ... +----------------+----------+- | % | jeffrey | ... | thomas.loc.gov | | ... +----------------+----------+- 排序後的表看起來像這樣： +----------------+----------+- | Host | User | ... +----------------+----------+- | thomas.loc.gov | | ... | % | jeffrey | ... +----------------+----------+- 一個由jeffrey從thomas.loc.gov的連接被第一個條目匹配，
