MySQL的存儲過程，沒錯，看起來好生僻的使用場景。問題源于一個開發(fā)同學(xué)提交了權(quán)限申請的工單，需要開通一些權(quán)限。
成都創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比益陽網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式益陽網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋益陽地區(qū)。費用合理售后完善，10余年實體公司更值得信賴。
本來是一個很正常的操作，但在我來看是比較著急且緊迫的，說來慚愧，忙著方向規(guī)劃和開發(fā)的事情，這個基礎(chǔ)的操作功能竟然給忽略了，所以看到目前的一些實現(xiàn)方式，還是希望能夠做一些細(xì)小的事情把這些重復(fù)性的工作給解放了。
當(dāng)然我決定把一些基礎(chǔ)性的工作接過來，一方面是給同事減壓，另一方面是在做一個完整的體驗，因為很多需求和痛點通過實踐是能夠很容易捕捉到重點的，如果我覺得不合理，那么這個過程中勢必會有一些改進的地方。比如部署安裝，比如權(quán)限開通。數(shù)據(jù)庫的權(quán)限開通就是一個相對典型的案例，而存儲過程的權(quán)限開通甚至都有點讓人懷疑人生了。
問題的場景還是很基礎(chǔ)的，開發(fā)同學(xué)需要開通一些基礎(chǔ)的權(quán)限，在標(biāo)記權(quán)限的時候聲明需要增刪改查的權(quán)限，還有DDL的權(quán)限，比如drop,alter,create等等?？吹竭@里，我就感覺不太妥了，什么樣的操作竟然需要這么大的權(quán)限呢。
簡單聲明了下立場，開發(fā)同學(xué)的想法是能夠方便管理，于是乎我就直接招過去了，簡單溝通下，其實發(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，默認(rèn)創(chuàng)建是definer，如果需要開放給其他的用戶調(diào)用，則建議是設(shè)置為invoker.
所以很簡單的一句：
grant execute,alter procedure on xxx.xxx to xxx@'xxxx';
但是很不幸的，開發(fā)同學(xué)反饋，他們通過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'即可
所以細(xì)粒度的權(quán)限控制就是這么糾結(jié)，但是確實有效。
比如我們舉一反三一下，我們知道MySQL里的all privileges算是一個很大的權(quán)限，但是里面包含多少種權(quán)限，可能我們沒有清晰的概念。
我們就完全可以通過細(xì)粒度的權(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)包含了我們需要的細(xì)粒度權(quán)限mysql.proc，如果要抽絲剝繭，基本就是這樣的套路。
補充:下面看下mysql創(chuàng)建存儲過程權(quán)限問題
首先，在mysql存儲過程出現(xiàn)的同時，用戶權(quán)限也增加了5種，其中和存儲過程有關(guān)的權(quán)限有 三種：
在使用GRANT創(chuàng)建用戶的時候分配這三種權(quán)限。 存儲過程在運行的時候默認(rè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)限的用戶，罵他吧，他是故意的。
當(dāng)然這樣的用戶建立的存儲過程倒并不是完全不能使用，創(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)限，我們可以放心大膽的使用存儲過程，不用擔(dān)心安全問題了。
總結(jié)
以上所述是小編給大家介紹的MySQL存儲過程的權(quán)限問題小結(jié)，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對創(chuàng)新互聯(lián)網(wǎng)站的支持！
重慶分公司
重慶分公司
