WL#9049: Add a dynamic privilege for stored routine backup

Affects: Server-8.0   —   Status: Complete

Add a system privilege using which a stored routine's (i.e
Stored Procedure's or Stored Function's) exact create string
(SP/SF body text) can be obtained to backup and re-create
the stored routine.

Functional requirements:
````````````````````````
 FR1: A new dynamic server privilege SHOW_ROUTINE must be
 created.

 FR2: User with SHOW_ROUTINE privilege must be able to
 SELECT the ROUTINE_DEFINITION column of all rows present in
 information_schema.routines.

 FR3: User with SHOW_ROUTINE privilege must be able to view
 the "Create Procedure" column of all stored procedures
 using SHOW CREATE PROCEDURE.

 FR4: User with SHOW_ROUTINE privilege must be able to view
 the "Create Function" column of all stored functions using
 SHOW CREATE FUNCTION.

 FR5: User with SHOW_ROUTINE privilege must be able to view
 the instructions of any stored procedure using SHOW
 PROCEDURE CODE.

 FR6: User with SHOW_ROUTINE privilege must be able to view
 the instructions of any stored function using SHOW FUNCTION
 CODE.

 FR7: User with SHOW_ROUTINE privilege must be able to view
 the properties of all stored procedures using SHOW
 PROCEDURE STATUS.

 FR8: User with SHOW_ROUTINE privilege must be able to view
 the properties of all stored functions using SHOW FUNCTION
 STATUS.

 FR9: SHOW_ROUTINE privilege must be granted to the root
 user during database initialization.

 FR10: Output of SHOW GRANTS must show the newly introduced
 privilege if granted.


Upgrade Related:
----------------

 U1) Upon upgrade from 5.7, user having global SELECT
 privilege must be granted SHOW_ROUTINE, provided that there
 isn't already a user who has the privilege SHOW_ROUTINE.

 U1) Upon upgrade from lower 8.0.x version, user having
 global SELECT privilege must be granted SHOW_ROUTINE,
 provided that there isn't already a user who has the
 privilege SHOW_ROUTINE.


I. INTRODUCTION:
````````````````

 1. Why do we need a new privilege?
 ----------------------------------
 In 5.7, full access to routine information (including the
 routine code) is provided to the definer of routine and to
 the user having SELECT privilege on mysql.proc. 

 In 8.0, as part of WL#7897, mysql.proc table is removed and
 this information is present in Data Dictionary (which is
 not user facing). 
 
 This meant that non-definer user could not have full access
 on the routine. So backup of routine or getting exact
 create string of stored routine was not possible. So as
 workaround for this issue, full access on stored routine
 was provided to any user having global SELECT privilege.

 This brought the requirement for a new privilege
 SHOW_ROUTINE in order to provide an alternative to granting
 the global SELECT privilege which has a broader scope.


 2. Statements that show the SP/SF create string/code:
 -----------------------------------------------------

  a) SHOW CREATE PROCEDURE|FUNCTION test.routine1; 

  b) SELECT ROUTINE_DEFINITION
      FROM information_schema.routines
      WHERE ROUTINE_SCHEMA="test" 
      AND ROUTINE_NAME="routine1";
  
  c) SHOW PROCEDURE|FUNCTION CODE test.routine1; 

  2.1. Other statements affected:
  -------------------------------
    
    a) SHOW PROCEDURE|FUNCTION STATUS 
        WHERE db="test" 
        AND name="routine1";


 3. Current behaviour:
 ---------------------

  a) Conditions required for a user "user@host" to view the
     create string / code (as well as all other properties)
     of a SP/SF "test.routine1" using the statements
     specified in B is:

      i) "user@host" is the definer of the routine.
      
      (or)

      ii) Global select privilege:
          ------------------------
          GRANT SELECT  ON *.*  TO user@host;

          DISADVANTAGE: Reusing global select privilege
          means granting a very broad privilege for a very
          narrow requirement.

  b) In case "user@host" has any of the below privileges,
      - CREATE ROUTINE
      - ALTER ROUTINE
      - EXECUTE
      either at global level or schema level, then the user
      is able to view all other properties of the routine,
      except for its create string (using statements 2.a,
      2.b, or 2.1.a). 

  In the following section, design to solve the problem
  noted in 3.a.ii is discussed.


II. DESIGN:
```````````

 1. The new SHOW_ROUTINE privilege:
 ----------------------------------

  This dynamic server privilege would allow a user owning it
  to backup the create string of all stored routines in the
  MySQL instance.

  LIMITATION: Dynamic privileges can only be granted at the
  global level, and not at a schema level. This is fine
  considering that the privilege will be used only to take
  backup of all stored routines in a MySQL instance.


 2. Changes to current behaviour:
 --------------------------------

 - User having SHOW_ROUTINE privilege will be able to view
   the create string / code of all stored routines.

 - Current behaviour specified in section I.3. will be
   retained.

    Q) Why should not user with database specific SELECT
    privilege also be able to view database specific
    procedure code?

    A) The goal is to move away from reusing SELECT
    privilege.

    Q) Why should not user with global or database specific
    CREATE ROUTINE/ALTER ROUTINE privilege also be able to
    view all / database specific procedure code?

    A) (Harin) User creating a routine need not see the code
    of other routines. They can see the code of the routines
    which they defined. User altering a routine cannot alter
    its definition in the first place, so there is no
    requirement to view it. 


III. UPGRADE:
`````````````
 On upgrade, SHOW_ROUTINE will be assigned to users having
 global SELECT privilege, provided that there isn't already
 a user who has the privilege SHOW_ROUTINE

 This applies to both upgrade from 5.7 as well as upgrade
 from lower 8.0.x version.

 Reason: The global SELECT privilege was used as a
 workaround which may eventually be removed (see section
 I.1).


IV. PERFORMANCE:
````````````````
 There shouldn't be any performance issues caused by this
 WL's changes.


V. DOCUMENTATION:
`````````````````
 Update to documentation is required specifying new privilege
 and its behaviour with the affected statements in section 2.