MySQL root用戶登錄的幾個小問題(r12筆記第67天)

  今天和同事聊了聊技術的事情，聊到BAT里面的一些高大上的系統和設計，相比總是會有些差距，不過像那樣體量的公司知識沉淀很深，所以能夠做好我們力所能及的事情，把它細化做好，也是一種進步和改進。

   如果你老是覺得自己的環境受限，有各種KPI或者是成本的考量，做事情從下往上去推動很難，這些都是實際的困難，很多公司都是存在這樣的問題的。在資源受限方面，我尤其糾結，舉個有意思的小例子，如果我收到一條報警，提示數據庫表空間不足了，那就添加一個數據文件唄，結果數據庫層面的空間問題解決了，而馬上會收到一個系統空間不足的報警，碰到這種情況，你自己體會，心情肯定是很復雜的。

   今天碰到的一個案例比較特別，是關于MySQL登錄的，數據庫環境是5.6版本。

> select version();
+-----------------+
| version()       |
+-----------------+
| 5.6.23-72.1-log |
+-----------------+
1 row in set (0.01 sec)今天同事問我一個問題，想讓我看看某個數據庫用戶的權限問題，我登錄到服務器端之后，一切都很順利。

# mysql
Logging to file '/home/mysql/query.log'
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 52625
Server version: 5.6.23-72.1-log Percona Server (GPL), Release 72.1, Revision 0503478一切都很正常，然后我準備看看連接到數據庫的線程情況。

> show processlist;
ERROR 1227 (42000): Access denied; you need (at least one of) the PROCESS privilege(s) for this operation竟然拋出了這個奇怪的錯誤，如果想查看數據字典中的信息，也被禁止了。

> select user,host from mysql.user;
ERROR 1142 (42000): SELECT command denied to user ''@'localhost' for table 'user'   這個時候就很糾結了，我堂堂的root用戶竟然登錄不了MySQL了，別說給同事排除故障，自己都登錄不了了。

帶著疑問，我查看了error log,竟然沒有發現什么相關的異常信息。

   這個問題該怎么繼續往下走，如果要做改動，影響到現有的測試用戶就不好了，盡管是測試環境，重啟服務之類的還是要和開發同學充分溝通之后才能動手，況且我是幫忙查看這個環境，更不能隨便改動了。

  對于這個問題讓我有些焦慮的時候，我想到之前還真給自己留了一道后門，那就是之前幫他們處理問題的時候，我在自己的服務器端設定了一個用戶，來測試數據庫的連接情況，沒想到這樣一個無心之舉就成了分析這個問題的最后一把鑰匙。

   很快，我從安全認證的中控客戶端登錄到了這臺MySQL服務器，連接數有100多個。一邊感嘆自己的英明，一邊速速分析問題。

這個數據庫中有10個左右的數據庫用戶，大體是這樣的內容，做了修改。

> select user,host from mysql.user;
+----------------+-----------------------------+
| user           | host                        |
+----------------+-----------------------------+
| cloud_test     | %                           |
| cloudcs_app    | %                           |
| root           | %                           |
| cloud_test     | 10.127.138.107              |
| root           | 10.127.138.107              |
|                | localhost                   |
| jeanron        | test_user%                  |
+----------------+-----------------------------+查看show process的信息，看到是用戶是root

| 52629 | root           | localhost       
+-------+----------------+------------查看root@localhost的權限，竟然沒有。

> show grants for root@'localhost';
ERROR 1141 (42000): There is no such grant defined for user 'root' on host 'localhost'這個時候我們停一下，在這個場景中，系統mysql命令直接連接進來的是root@localhost嗎？從錯誤日志來看不是，而從線程信息來看是，所以我們需要進一步分析一下，問題在哪里。

雖然服務端直接mysql命令登錄后，查看不了線程情況，查看不了數據字典，但是show grants這個命令是可以的。

> show grants;
+------------------------
| Grants for @localhost                                                   
+------------------------
| GRANT USAGE ON *.* TO ''@'localhost'可以看出來，登錄的用戶是''@'localhost',而不是root@'localhost'，這個環境中沒有配置root@'localhost'用戶。

然后再次查看mysql.user的情況，就會發現下面的配置比較特別。root使用了寬泛的域名方式，允許不同的IP來訪問，而另外有一條記錄是指定的IP。

| root           | %                           |
| root           | 10.127.138.107              |
|                | localhost                   |這個能夠說明什么呢，也就是說使用root@localhost的效果和root@'%'是類似的。而這個''@localhost目前是默認的連接方式，需要說的是，在這個配置下是優先的。

我們初始化一個mysql環境后，一般mysql.user的內容是這樣的，比如一個5.7的環境。

mysql> select user,host from mysql.user;
+-----------+-----------+
| user      | host      |
+-----------+-----------+
| mysql.sys | localhost |
| root      | localhost |
+-----------+-----------+
2 rows in set (0.00 sec)默認的連接方式是root@'localhost'

而在上面的場景中，沒有root@'localhost'的配置，就優先使用了''@'localhost'這個用戶。

為什么會有這個問題呢，和開發同學溝通之后，定位分析，發現原來之前這個服務器的IP發生過變化。后來開發同學自己也做了一些修改和配置，就是現在的情況了。

  對于這種情況怎么修復呢，我的想法是刪除匿名用戶，服務端不啟用密碼，即root@'localhost',而客戶端連接則使用域名解析的方式，但是對開發同學不開放root權限，所以我們刪除root@'%' 用戶。

刪除匿名用戶''@'localhost'

> drop user ''@localhost;
刪除最高權限的root用戶，不對外提供任意的權限訪問。

drop user root@'%';修改那個IP發生變化的服務器配置，修改為localhost

> update mysql.user set host='localhost' where user='root' and host='10.127.138.107';設置密碼為空，最后使用flush privileges即可。

  這樣一來，我們的預期效果就達到了，使用mysql登錄即可。

> show grants;
+----------------------------
| Grants for root@localhost