MySQL存儲過程的權限問題小結

MySQL的存儲過程，沒錯，看起來好生僻的使用場景。問題源于一個開發同學提交了權限申請的工單，需要開通一些權限。

本來是一個很正常的操作，但在我來看是比較著急且緊迫的，說來慚愧，忙著方向規劃和開發的事情，這個基礎的操作功能竟然給忽略了，所以看到目前的一些實現方式，還是希望能夠做一些細小的事情把這些重復性的工作給解放了。

當然我決定把一些基礎性的工作接過來，一方面是給同事減壓，另一方面是在做一個完整的體驗，因為很多需求和痛點通過實踐是能夠很容易捕捉到重點的，如果我覺得不合理，那么這個過程中勢必會有一些改進的地方。比如部署安裝，比如權限開通。數據庫的權限開通就是一個相對典型的案例，而存儲過程的權限開通甚至都有點讓人懷疑人生了。

問題的場景還是很基礎的，開發同學需要開通一些基礎的權限，在標記權限的時候聲明需要增刪改查的權限，還有DDL的權限，比如drop,alter,create等等。看到這里，我就感覺不太妥了，什么樣的操作竟然需要這么大的權限呢。

簡單聲明了下立場，開發同學的想法是能夠方便管理，于是乎我就直接招過去了，簡單溝通下，其實發現他們的需求場景還是很常規的，他們需要動態創建一些日表，那么需要create權限在評估之后是可以給與的，而對于一般的用戶而言，create的權限是不建議開放的，主要的出發點就是能夠對SQL進行一些基本的審核，哪怕是人工審核還是平臺審核都是一個需要的過程。所以溝通了一圈發現，開通的權限就可以迅速裁剪，對他們而言，修改存儲過程的邏輯也是需要的，因為在一些特定的場景下，他們對邏輯的控制希望能夠更加靈活。

好了，基礎的背景介紹完了。賦予基本的表的權限，賦予存儲過程的權限，存儲過程的這個地方需要注意一個重要的點是SQL SECURITY，默認創建是definer，如果需要開放給其他的用戶調用，則建議是設置為invoker.

所以很簡單的一句：

grant execute,alter procedure on xxx.xxx to xxx@'xxxx'; 

但是很不幸的，開發同學反饋，他們通過SQLyog或者是Navicator打開的時候，竟然看不到存儲過程的內容。

因為我們沒有select procedure或者view procedure的權限，所以我們幾乎再無從干預了。

使用命令行的方式能夠復現出這個問題:

沒有存儲過程的實質性內容。在那兒折騰了好一會，發現是個老問題了，10多年前的老問題了。

https://bugs.mysql.com/bug.php?id=20235

問題的解決其實很簡單，就是需要這樣一句:

grant select on mysql.proc to xxxx@'xxxx'即可 

所以細粒度的權限控制就是這么糾結，但是確實有效。

比如我們舉一反三一下，我們知道MySQL里的all privileges算是一個很大的權限，但是里面包含多少種權限，可能我們沒有清晰的概念。

我們就完全可以通過細粒度的權限控制來反推。

比如創建一個用戶，賦予all privileges的權限。

mysql> grant all privileges on test.* to 'jeanron'@'%' identified by 'jeanron100'; 
Query OK, 0 rows affected, 1 warning (0.00 sec) 

包含的權限如下：

mysql> show grants for jeanron; 
+---------------------------------------------------+ 
| Grants for jeanron@%        | 
+---------------------------------------------------+ 
| GRANT USAGE ON *.* TO 'jeanron'@'%'    | 
| GRANT ALL PRIVILEGES ON `test`.* TO 'jeanron'@'%' | 
+---------------------------------------------------+ 
2 rows in set (0.00 sec) 

我們做一下收縮。

mysql> revoke insert on test.* from jeanron@'%'; 
Query OK, 0 rows affected (0.00 sec) 
喏，all privileges的權限就現出原形了。
mysql> show grants for jeanron; 
| Grants for jeanron@% 
+------------------------------------------------------------------------------------------------------ 
| GRANT USAGE ON *.* TO 'jeanron'@'%' 
| GRANT SELECT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON `test`.* TO 'jeanron'@'%' | 

所以在上面的問題中，其實如果select on *.*其實已經包含了我們需要的細粒度權限mysql.proc，如果要抽絲剝繭，基本就是這樣的套路。

補充:下面看下mysql創建存儲過程權限問題

首先，在mysql存儲過程出現的同時，用戶權限也增加了5種，其中和存儲過程有關的權限有 三種：

• ALTER ROUTINE 編輯或刪除存儲過程
• CREATE ROUTINE 建立存儲過程
• EXECUTE 運行存儲過程
  

在使用GRANT創建用戶的時候分配這三種權限。 存儲過程在運行的時候默認是使用建立者的權限運行的。

需要注意的是在一個用戶擁有建立存儲過程的權限時，如果其沒有對于select、update或delete等權限的話，雖然操作數據的存儲過程可以建立，但調用存儲過程的話仍是無法成功的，會返回權限錯誤，就算擁有運行存儲過程的權限也一樣。所以，如果有人給你建立了一個沒有select、update、delete權限只有CREATE ROUTINE權限的用戶，罵他吧，他是故意的。

當然這樣的用戶建立的存儲過程倒并不是完全不能使用，創建存儲過程中有一個特征子句可以讓存儲過程使用運行者的權限，在建立存儲過程后只要加上SQL SECURITY INVOKER特征子句就可以了。

如下。

 CREATE PROCEDURE p() SQL SECURITY INVOKER 這樣的話就可以分配兩批人，一批給與創建存儲過程的權限，作為開發者，一批給與運行存儲過程和select、update、delete權限，作為測試者。（腦筋秀逗了） 有了這種權限分配，mysql的安全性完全不需要在功能層去保護了，我通過root用戶建立的存儲過程，但是在功能層用一個只擁有運行存儲過程權限的用戶來調用。那么，你就算從功能層上得到數據庫的用戶名和密碼，并且模擬了ip，也不能得到你想要的任何東西。 有了權限，我們可以放心大膽的使用存儲過程，不用擔心安全問題了。

總結

以上所述是小編給大家介紹的MySQL存儲過程的權限問題小結，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對億速云網站的支持！