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

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

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

問題的場景還是很基礎(chǔ)的，開發(fā)同學需要開通一些基礎(chǔ)的權(quán)限，在標記權(quán)限的時候聲明需要增刪改查的權(quán)限，還有DDL的權(quán)限，比如drop,alter,create等等?？吹竭@里，我就感覺不太妥了，什么樣的操作竟然需要這么大的權(quán)限呢。

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

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

所以很簡單的一句：

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

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

因為我們沒有select procedure或者view procedure的權(quán)限，所以我們幾乎再無從干預(yù)了。

使用命令行的方式能夠復(fù)現(xiàn)出這個問題:

沒有存儲過程的實質(zhì)性內(nèi)容。在那兒折騰了好一會，發(fā)現(xiàn)是個老問題了，10多年前的老問題了。

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

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

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

所以細粒度的權(quán)限控制就是這么糾結(jié)，但是確實有效。

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

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

比如創(chuàng)建一個用戶，賦予all privileges的權(quán)限。

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

包含的權(quán)限如下：

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的權(quán)限就現(xiàn)出原形了。
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 *.*其實已經(jīng)包含了我們需要的細粒度權(quán)限mysql.proc，如果要抽絲剝繭，基本就是這樣的套路。

補充:下面看下mysql創(chuàng)建存儲過程權(quán)限問題

首先，在mysql存儲過程出現(xiàn)的同時，用戶權(quán)限也增加了5種，其中和存儲過程有關(guān)的權(quán)限有 三種：

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

在使用GRANT創(chuàng)建用戶的時候分配這三種權(quán)限。 存儲過程在運行的時候默認是使用建立者的權(quán)限運行的。

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

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

如下。

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

總結(jié)

以上所述是小編給大家介紹的MySQL存儲過程的權(quán)限問題小結(jié)，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！