MySQL資料庫許可權體系入門(5)---管理資料庫許可權

junsansi發表於2010-10-25
MySql資料庫

3.2、資料庫

　　MySQL中的資料庫(DB)從功能上來看，有點兒類似ORACLE資料庫中的表空間，都是一個提供物件儲存的空間(information_schema除外，該db比較特殊，後面章節將專門描述)，但是MySQL中的資料庫與ORACLE中的表空間不同也表現的非常突出。比如說，MySQL中的資料庫，不過是對應作業系統中的一個目錄，也就是說，不必通過create database語句建立，直接在作業系統一級指定位置建立一個目錄，然後到mysql命令列下show databases，也是能看到的。

　　設定資料庫級別的許可權，是指在指定的資料庫中，擁有[所有]物件的[所有]許可權，這部分許可權資訊記錄mysql.db和mysql.host表。

　　這裡特別提一下mysql.host表，該表在5.1版本及之前版本中的設計也比較特殊，預設情況下GRANT/REVOKE語句並不觸發該表資料的讀寫，因此多數情況下該表基本沒啥用，不過某些特殊情況下，DBA可以手動操作(insert/update)該表來實現某些特殊的需求，比如說將內網中的某些伺服器加入該表並授予所有許可權，所有管理操作都通過這些伺服器進行，又或者明確指定某些伺服器不具備管理許可權等等諸如此類，換個角度來看的話，如果沒有類似需求，那就可以完全不考慮mysql.host表了，起碼在5.1版本中是這樣。

　　先收回jss@%在全域性的create許可權，收回許可權使用revoke語句，語法跟grant很像，操作如下：

    mysql> revoke create on *.* from jss@'%';

    Query OK, 0 rows affected (0.00 sec)

    mysql> select * from user where user='jss'\G

    *************************** 1. row ***************************

                     Host: %

                     User: jss

                 Password: *284578888014774CC4EF4C5C292F694CEDBB5457

              Select_priv: N

              Insert_priv: N

              Update_priv: N

              Delete_priv: N

              Create_priv: N

                Drop_priv: N

              Reload_priv: N

            Shutdown_priv: N

             Process_priv: N

                File_priv: N

               Grant_priv: N

          References_priv: N

               Index_priv: N

               Alter_priv: N

             Show_db_priv: N

               Super_priv: N

    Create_tmp_table_priv: N

         Lock_tables_priv: N

             Execute_priv: N

          Repl_slave_priv: N

         Repl_client_priv: N

         Create_view_priv: N

           Show_view_priv: N

      Create_routine_priv: N

       Alter_routine_priv: N

         Create_user_priv: N

               Event_priv: N

             Trigger_priv: N

                 ssl_type: 

               ssl_cipher: 

              x509_issuer: 

             x509_subject: 

            max_questions: 0

              max_updates: 0

          max_connections: 0

     max_user_connections: 0

    1 row in set (0.00 sec)

　　多說一句，jss@%只具有create許可權，因此執行revoke時，直接revoke all privileges也是可行的。

　　嘗試授予jss@%操作jssdb庫的create許可權，操作如下：

    mysql> grant create on jssdb.* to jss@'%';

    Query OK, 0 rows affected (0.00 sec)

    mysql> select * from db where user='jss'\G;

    *************************** 1. row ***************************

                     Host: %

                       Db: jssdb

                     User: jss

              Select_priv: N

              Insert_priv: N

              Update_priv: N

              Delete_priv: N

              Create_priv: Y

                Drop_priv: N

               Grant_priv: N

          References_priv: N

               Index_priv: N

               Alter_priv: N

    Create_tmp_table_priv: N

         Lock_tables_priv: N

         Create_view_priv: N

           Show_view_priv: N

      Create_routine_priv: N

       Alter_routine_priv: N

             Execute_priv: N

               Event_priv: N

             Trigger_priv: N

    1 row in set (0.00 sec)

　　這樣，jss就擁有了在jssdb庫中建立表物件的許可權，當然，也僅限於建立。

　　綜合來看，全域性和資料庫都是兩個粒度比較粗的許可權級別，我們再來總結一下與之相關的資料字典：

  • mysql.user表決定是否允許或拒絕到來的連線。對於允許的連線，user表授予的許可權指出使用者的全域性(超級使用者)許可權。這些許可權適用於伺服器上的all資料庫。
  • mysql.db表範圍列決定使用者能從哪個主機存取哪個資料庫。許可權列決定允許哪個操作。授予的資料庫級別的許可權適用於資料庫和它的表。
  • 當你想要一個給定的db表應用於若干主機時，db和host表一起使用。例如，如果你想要一個使用者能在你的網路從若干主機使用一個資料庫，在使用者的db錶行的Host值設為空值，然後將那些主機的每一個移入host表。

3.2.1 有趣的test庫

　　Mysql安裝後，預設建立的test資料庫許可權比較怪異，所有可連線的使用者都能夠擁有許可權訪問該庫，並操作其中的物件。這是怎麼實現的呢，其實很簡單，檢視一下mysql.db即可明瞭：

    mysql> select * from db where db like 'test%'\G;

    *************************** 1. row ***************************

                     Host: %

                       Db: test

                     User: 

              Select_priv: Y

              Insert_priv: Y

              Update_priv: Y

              Delete_priv: Y

              Create_priv: Y

                Drop_priv: Y

               Grant_priv: N

          References_priv: Y

               Index_priv: Y

               Alter_priv: Y

    Create_tmp_table_priv: Y

         Lock_tables_priv: Y

         Create_view_priv: Y

           Show_view_priv: Y

      Create_routine_priv: Y

       Alter_routine_priv: N

             Execute_priv: N

               Event_priv: Y

             Trigger_priv: Y

    *************************** 2. row ***************************

                     Host: %

                       Db: test\_%

                     User: 

              Select_priv: Y

              Insert_priv: Y

              Update_priv: Y

              Delete_priv: Y

              Create_priv: Y

                Drop_priv: Y

               Grant_priv: N

          References_priv: Y

               Index_priv: Y

               Alter_priv: Y

    Create_tmp_table_priv: Y

         Lock_tables_priv: Y

         Create_view_priv: Y

           Show_view_priv: Y

      Create_routine_priv: Y

       Alter_routine_priv: N

             Execute_priv: N

               Event_priv: Y

             Trigger_priv: Y

    2 rows in set (0.00 sec)

　　你看，從許可權上來看，host為%，user為空，這就說明了不限制的，所有能連線到MySQL的使用者，幾乎都擁有test庫的所有許可權。

　　這無異存在安全上的隱患，先不說在其中建立的重要物件可被任何人訪問，就算該庫中沒有任何物件，假如有人想惡意破壞DB服務，只要登入，然後在該庫建立一個超大物件，把空閒空間全部佔滿，就相當於變相達到了破壞db服務的目地。對於這種庫沒啥好說的，該咋處理就咋處理吧~~

3.2.2 並不存在的INFORMATION_SCHEMA庫

　　如同ORACLE中那堆all_*/user_*表並非真正的表，MySQL中的Information_schema也並不是真正的庫，而是由MySQL自動維護的一組虛擬表，跟ORACLE資料庫中的資料字典表非常類似，都是使用者能看卻不能改(不能直接改)。

　　所有登入到MySQL的使用者都能訪問INFORMATION_SCHEMA資料庫，以及其中的表，當然，看到的都是自己有許可權看到的物件。比如說擁有jssdb資料庫所有許可權的jss使用者，use information_schema資料庫後，能夠檢視jssdb下的所有表、檢視、觸發器、過程等所有相關物件的後設資料。

　　使用者不能對INFORMATION_SCHEMA資料庫中的物件做授權，比如說授予information_schema.tables的select許可權給jss使用者，這樣操作肯定會失敗，即使是root使用者也不行。

=======================================

檢視之前的連載：

MySQL資料庫許可權體系入門(4)---管理全域性許可權

MySQL資料庫許可權體系入門(3)---管理使用者許可權

MySQL資料庫許可權體系入門(2)---建立使用者

MySQL資料庫許可權體系入門(1)---工作原理

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7607759/viewspace-676674/，如需轉載，請註明出處，否則將追究法律責任。

相關文章