MySQL 5.6 - User cannot view stored procedure code - mysql

We created a user/login for some devs, and we have an issue where this user/login cannot view stored procedure code.
This is for MySQL 5.6.
I checked the GRANTS and also the information_schema (schema_privileges) and things look "good" to me.
Here are the commands I used to GRANT the database access and privileges:
GRANT SELECT, INSERT, UPDATE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `mydatabase`.* TO 'dev-user'#'%' ;
After that, I run the FLUSH PRIVILEGES command.
And, when I run SHOW GRANTS for `dev-user` , I get the following response:
GRANT SELECT, INSERT, UPDATE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON mydatabase.* TO 'dev-user'#'%'
After that the user runs the command SHOW CREATE procedure mydatabase.sp_test and the output has NULL in the CREATE PROCEDURE Column.
This same user/login can create a new procedure and running SHOW CREATE procedure has the procedure code visible in that CREATE PROCEDURE column.
And, as a quick test, i created another user with GRANT ALL PRIVILEGES on the database and i get the same results. That user also not see the stored procedure code.
When I run a query on the information_schema.SCHEMA_PRIVILEGES system table, i can see that the user has included:
ALTER
ALTER ROUTINE
CREATE
CREATE ROUTINE
Does anyone have any suggestions or can see something i am missing, or forgot?
Thanks for any help

As stated in the documentation:
To use either statement, you must be the user named in the routine DEFINER clause or have SELECT access to the mysql.proc table.
So grant them that access:
GRANT SELECT ON mysql.proc TO 'dev-user'#'%';
BTW, it's not necessary to use FLUSH PRIVILEGES after the GRANT statement. See MySQL: When is Flush Privileges in MySQL really needed?

Related

trying to get ocelotgui debugging working

I am preparing to write a complex stored procedure. I figure will need a debugger going so I am trying to use ocelotgui. I have installed it and can connect to my database in mysql. When I type $INSTALL which is required to set up the debugger I am getting this error:
$INSTALL
Need create privilege on xxxmdbug.. Need select privilege on xxxmdbug.. Need insert privilege on xxxmdbug.. Need delete privilege on xxxmdbug.. Need update privilege on xxxmdbug.. Need drop privilege on xxxmdbug.. Need create routine privilege on xxxmdbug.. Need alter routine privilege on xxxmdbug..
It seems that ocelotgui creates a database called xxxmdbug but for some reason it can't on my system. I am running mySQL in Docker and I have modified the mysql.sql to have the following lines dealing with xxxmdbug.
CREATE DATABASE IF NOT EXISTS subs;
CREATE DATABASE IF NOT EXISTS xxxmdbug;
GRANT ALL PRIVILEGES ON subs.* To 'admin'#'%';
GRANT ALL PRIVILEGES ON xxxmdbug.* To 'admin'#'%';
It seems that I can't login with root so that I can GRANT my actual user the privileges. I though that the password for root was "", but I guess not. Anyone?
I assume you downloaded ocelotgui 1.2 from https://github.com/ocelot-inc/ocelotgui.
You might be seeing an error if database xxxmdbug already exists
(if so, drop it). But if the problem is lack of privileges
(you need create, drop, create routine, alter routine, select, insert, update, delete, select on xxxmdbug.*), then there's
nothing ocelotgui can do, good luck finding the root password.

GRANT ALL needs additional privileges to alter or drop stored procedures?

Hello everybody.
I am using MariaDB 10.0.24 on Windows 7.
I made a user using this command.
GRANT ALL ON target_DB.* TO `user_name`#`%` IDENTIFIED BY 'user_pass';
This works fine. But when the user 'user_name' tries to alter or drop stored procedures, below error is occurred.
Unable to retrieve information. Please check your privileges. For
routines (stored procedures and functions) you need SELECT privilege
to mysql.proc if you are not the owner of the routines.
After googling, I found this. https://dev.mysql.com/doc/refman/5.7/en/stored-routines-privileges.html
My questions are...
'GRANT ALL' does not cover privileges for the stored routines?
If above answer is yes, what should I do for the 'user_name' to alter or drop stored routines?

Provide only GRANT EXECUTE 'procedure' to a user (No select or insert permissions)

I was wondering if it's possible to grant EXECUTE permissions to a user without granting SELECT, INSERT etc. permissions on the table that a procedure runs on?
Using it for a Logins table for a webapp. MySQL is running in a Docker container. SQL for creating procedures is copied across as part of the docker build process (when run, the sql is used in entrypoint.sh). Login_db is created when running the container (-e flag).
I'd like to remove the GRANT SELECT line from below so, no matter what happens, the webapp server can never run a SELECT query - such as doing SELECT * FROM logins.
CREATE USER 'logins'#'172.24.0.7' IDENTIFIED BY 'some-password';
GRANT SELECT, INSERT, UPDATE on logins_db.login TO 'logins'#'172.24.0.7';
GRANT EXECUTE ON PROCEDURE logins_db.sp_login16 TO 'logins'#'172.24.0.7';
FLUSH PRIVILEGES;
This doesn't solve it - as being the table owner would expose the same privileges:
Execute stored proc fails with GRANT EXECUTE because of table permissions
This might explain why I can't, but the table names are a bit odd to me (MySQL newbie - I'm under the impression that mysql.proc is a system table, so not sure if it applies):
How to grant execute on specific stored procedure to user
Could it be that root doesn't have SELECT privileges when creating the procedure and so the the logins user cannot run it? (Because Docker MySQL runs entrypoint.sh and then the environment variable)?
The procedure code is here (I know, not the most elegant) - could I GRANT and then REVOKE privileges for the logins user within this, considering the DEFINER is root ?
CREATE DEFINER=`root`#`localhost` PROCEDURE `sp_login16`(
IN p_email VARCHAR(120),
IN p_password VARCHAR(120))
BEGIN
SELECT user_id,user_password FROM login WHERE user_email = p_email;
Yes, you can do this by using sql security definer while declaring the stored procedure:
The SQL SECURITY characteristic can be DEFINER or INVOKER to specify
the security context; that is, whether the routine executes using the
privileges of the account named in the routine DEFINER clause or the
user who invokes it. This account must have permission to access the
database with which the routine is associated. The default value is
DEFINER. The user who invokes the routine must have the EXECUTE
privilege for it, as must the DEFINER account if the routine executes
in definer security context.
The DEFINER clause specifies the MySQL account to be used when
checking access privileges at routine execution time for routines that
have the SQL SECURITY DEFINER characteristic.
If a user value is given for the DEFINER clause, it should be a MySQL
account specified as 'user_name'#'host_name', CURRENT_USER, or
CURRENT_USER(). The default DEFINER value is the user who executes the
CREATE PROCEDURE or CREATE FUNCTION statement. This is the same as
specifying DEFINER = CURRENT_USER explicitly.
To sum it up: the user in the definer clause has to have the select / insert privileges to the underlying table in this ase, while the user who executes the stored proc must have execute privileges to the stored proc.
Added a new user ADMIN#localhost with SELECT, INSERT and UPDATE privileges. ADMIN then became the DEFINER for all the procedures, with 'logins'#'172.24.0.7' only being granted EXECUTE permissions. Runs perfectly now!
Apparently you can't use root in the way I was trying to. Kudos to #Shadow for pointing me in the right direction.
Setting up the admin user:
CREATE USER 'admin'#'localhost' IDENTIFIED BY '<password>';
GRANT SELECT, INSERT, UPDATE, DELETE ON db.table_name TO 'admin'#'localhost';
GRANT ALTER ROUTINE, CREATE ROUTINE, EXECUTE ON *.* TO 'admin'#'localhost';
FLUSH PRIVILEGES;
Defining a stored procedure that creates a entry using the limited admin user
DELIMITER $$
CREATE DEFINER=`admin`#`localhost` PROCEDURE `sp_createTableEntry`(
IN value_one VARCHAR(120),
IN value_two VARCHAR(200)
)
BEGIN
IF ( select exists (select 1 from table_name where column_one = value_one) ) THEN
select 'Column One Exists !!';
ELSE
insert into table_name
(
column_one,
column_two
)
values
(
value_one,
value_two
);
END IF ;
END $$
DELIMITER ;

How can I grant to the limited users to see the structure of mysql routines?

How can I grant somebody to see the structure of mysql routines?
The following command can be used to show the structure of routines:
show create function FUNCTION_NAME
or
show create procedure PROCEDURE_NAME
but It should be run by the user with grant all permission. I don't want to give grant all to the user. What is the exact grant I need or what is the alternative solutions?
from the manual
To use either statement, you must be the user named in the routine DEFINER clause or have SELECT access to the mysql.proc table.
So granting SELECT to the mysql.proc table should be sufficient.
For MySQL 8.20+ you can use:
GRANT SHOW_ROUTINE ON . TO username
MySQL 8 Reference

Meaning of Execute_priv on mysql.db table

I created user 'restriceduser' on my mysql server that is 'locked down'. The mysql.user table has a N for all priveledges for that account. The mysql.db table has Y for only Select, Insert, Update, Delete, Create, Drop; all other privileges are N for that account. I tried to create a stored procedure and then grant him access to run only that procedure, no others, but it does not work.
The user receives: Error: execute command denied to user 'restricteduser'#'%' for routine 'mydb.functionname'
The stored procedure:
CREATE DEFINER = 'restriceduser'#'%' FUNCTION `functionname`(sIn MEDIUMTEXT, sformat MEDIUMTEXT)
RETURNS int(11)
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
....
END;
The grant statement I tried:
GRANT EXECUTE ON PROCEDURE mydb.functionname TO 'restricteduser'#'%';
I was able to work around by modifying his mysql.db entry with
update mysql.db set execute_priv='Y' where user='restricteduser'
This seems to be more then I want, because it opens up permissions for him to run any stored procedure in that database, while I only wanted him to have permissions to run the designated function.
Does anyone see where my issue may lie?
The user table for the restricted user that you have created
will need execute_priv = 'Y'. This grant supersedes the db grant.