許可權系統工作原理 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：請求證實描述。 範圍欄位是字串，如下所述；每個欄位的預設值是Null 字元串： 欄位名 類型 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的串連被第一個條目匹配，
http://www.bkjia.com/PHPjc/532232.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/532232.htmlTechArticle許可權系統工作原理 MySQL許可權系統保證所有的使用者可以嚴格地做他們假定被允許做的事情。當你串連一個MySQL伺服器時， 你的身份由你從那連...
