all許可權使用者無法執行儲存過程

   我們使用儲存過程的時候，往往只注意要給呼叫儲存過程的賬號賦予相應許可權，但是實際上儲存過程定義使用者與這個儲存過程能否被執行有直接關係，如果不知道這點，即使呼叫儲存過程的賬號具備存相關許可權，一樣還是不能執行儲存過程。

語法：

CREATE DEFINER=`xx`@`%` PROCEDURE `mmm`

這裡DEFINER有兩種模式Security definer和Security invoker

Security definer： 

   definer：在執行儲存過程前驗證definer對應的使用者如：xx@%是否存在，以及是否具有執行儲存過程的許可權。

Security invoker

   invoker:在執行儲存過程時判斷呼叫該儲存過程的使用者是否有相應許可權。

   其實，用簡單明瞭語言解釋下可能更容易理解：

SECURITY DEFINER 表示定義者必須有相關許可權。

SECURITY INVOKER 表示只要呼叫者有相關許可權即可。

問題描述：

   今天一個別的部門的DBA同事，要我幫忙處理一個問題。說他們業務開發的程式不能正確執行儲存過程，由於他們的很多業務邏輯關係都是放在儲存過程中判斷，而非程式判斷。所以這個問題極其重要，直接導致了業務不可用。前端報錯感覺是許可權不夠，且所有呼叫儲存過程的賬號都是同一個aaa(這裡用aaa表示業務賬戶)，檢查了這個使用者的許可權，沒有問題，最後甚至賦予了all許可權，但問題依舊。到這他和他們部門同事都認為不再是許可權不夠的問題。嘗試了一些別的方法都無法解決，問題一直就卡在這了，所有人在那著急。

   我上去分析了一下，確實如他們描述一樣。到庫上隨機看了一個儲存過程c：

CREATE DEFINER=`xx_user`@`%` PROCEDURE `DBQ_MMM`  其它所有儲存過程皆是如此。  

 show grants for 'xxx_user'@'%' 檢視發現沒有EXECUTE 執行儲存過程的這個許可權

接著，show procedure status like 'c'

procedure.jpg

      注意Security_type這裡是DEFIN，所以雖然前端程式使用的是具有all許可權的aaa賬戶，但是定義者xxx_user沒有執行許可權。儲存過程依舊不能被執行，也就難怪為啥糾了結半天最大許可權的使用者依然還是沒有許可權了。至於這個使用者的EXECUTE許可權是人為revoke誤操作，還是以前使用的是INVOKER模式，那就不知道了。但是前者99%的可能。虛驚一場，真是小問題險些造成大事故啊。

解決方法:

      修改儲存過程定義使用者，給一個具有執行許可權的使用者即可

      如果是從別的庫導過來的，有大量儲存過程一個個修改太麻煩，提供兩個思路：

在匯出的sql中用sed替換，然後再匯入到 新庫中。

直接建立一個與原先庫中的定義使用者一樣的使用者。

©著作權歸作者所有：來自51CTO部落格作者等飛的旗的原創作品，如需轉載，請註明出處，否則將追究法律責任

故障mysql儲存過程