example:
A non-super user has been granted execute on a procedure that inserts into table "a". That user will see the database that table "a" is in with a "show databases", but will not be able see table "a" with a "show tables". But that same user can see basic procedure info with a "show procedure status".
This is for auditing and I would like to have the audit process as obscured as possible. If a user is granted execute on a procedure must that user have the ability to see the procedure? And must they be able to see the database that the procedure touches?
If you are the owner of the procedure or if you have access to mysql.proc table you can see the definition of the procedure as stated here.
So you would create the procedure as super and set DEFINER CURRENT_USER (so the procedure executes as super). Then make sure super has access to the table but that no one else does. That should protect both the table and the source but leave it possible to call on the procedure.
And it don't have to be super, can be any user that has access to the table.
Related
I'm struggling a little with MySQL stored procedures and getting a bit frustrated. I have a set of SPs created by Bob. As he is the DEFINER, only he can see the CREATE statement for them, amend them etc.
Mary can see Bob's stored procedures in the schema in MySQL Workbench, but can't see what they do - when she clicks on the SP and selects "Send to SQL Editor -> CREATE statement" nothing happens, because she's not the definer.
Coming from a MS SQL background this is a little bizarre to me. Is there any way I can set up a group (e.g. "DB_DEVS") and make this group the definer of the Stored Procs so Bob and Mary can see each other's code?
DEFINER always refers to the user who created the stored procedure. This can only be 1 user.
If Mary wants to see Bobs procedure, she could call:
SHOW CREATE PROCEDURE proc_name
To see the code of the procedure. She could also call the following to see the code:
SELECT ROUTINE_DEFINITION FROM information_schema.ROUTINES WHERE SPECIFIC_NAME='proc_name'
Heres how to enable Mary to access the view of the procedure via MySQL-Workbench:
By default, Mary is not able to send the create statement to the SQL-Editor. But this is just a privilege thing. Mary just needs a basic SELECT privilege in the mysql.proc table. To do this, run the following SQL-Statement (via Command line or directly in the Workbench):
GRANT SELECT ON mysql.proc TO 'mary'#'%'
This command enables Mary to access the Create-Statement from all hosts. If you want to limit it to a specific host you would do something like:
GRANT SELECT ON mysql.proc TO 'mary'#'192.168.2.1'
If Mary has the SELECT privilege she should be able to see the procedure after doing Send to SQL Editor -> CREATE statement
NOTE: In order to run the GRANT-Command you need to be logged in as user who has the privilege to grant privileges (e.g. root-user)
+++++++++++++++++++++++++EDIT+++++++++++++++++++++++++
There is a "quick and dirty" way to achieve this for a large number of users without writing for each user a new command to grant the privilege:
(make sure to do this with a user who has the privilege to insert rows via the Workbench)
Open a new SQL-Tab in your Workbench
Type SELECT * FROM mysql.tables_priv; and run it
Above the result-grid there should be the a small button which allows you to import data from a csv-File.
Create a CSV-File which looks like this:
%,mysql,jane,proc,root#localhost,"2016-02-19 22:51:47",Select,
%,mysql,max,proc,root#localhost,"2016-02-19 22:51:47",Select,
%,mysql,steve,proc,root#localhost,"2016-02-19 22:51:47",Select,
%,mysql,greg,proc,root#localhost,"2016-02-19 22:51:47",Select,
%,mysql,jamie,proc,root#localhost,"2016-02-19 22:51:47",Select,
...further users
jane, max, steve,... would be your users. Leave the other columns the way they are.
Import your csv-File
Run FLUSH PRIVILEGES in an SQL-Window (reloades privileges from priv-tables)
Finished! All your users can now access Stored Procedures
i have two databases, db1 and db2.
User man1 had all privileges to db1 but only executing provileges for all functions and procedures in db2.
Calling function db2.getValue from db1 is successful and returns correct values, also if call for db2.getValue is nested in a stored procedure.
Now i create a stored Procedure proc1 and within this procedure i use a cursor to fetch values (_val1, _val2,--) from a table in db1 and call db2.getValue(_val1).
Now somthing really strange happens:
The first loop from the cursor finish, but the value from db2.getValue is empty. At the end of this loop, the loop ends and stops.
Does anyone have a hint where the problem could be here? Calling db1.getValue(_val1) instead of db2.getValue(_val1) works fine.
Therefore my idea was that within the cursor, the privileges for db2 might be not the same?
Kind Regards Solick
Yes, by design, a cursor can behave differently than the same SELECT query might behave if it were executed by the user who called the procedure.
Stored programs and views are defined prior to use and, when referenced, execute within a security context that determines their privileges. These privileges are controlled by their DEFINER attribute, and, if there is one, their SQL SECURITY characteristic.
— http://dev.mysql.com/doc/refman/5.6/en/stored-programs-security.html
If you don't specify a DEFINER when you create a stored program (proc, function, trigger, or event) or a view, then the object, when accessed, runs with the privileges of the user who originally defined it, not the user who invoked it.
You have three options, here:
Verify or possibly modify the permissions of the current DEFINER user if appropriate; or,
Specify a different DEFINER user when defining the stored program or view... you can do this as long as you (the person creating the object) have the SUPER privilege, and users invoking (accessing) the object will temporarily have the rights of that DEFINER user instead; or,
Add SQL SECURITY INVOKER to the definition of procedures, functions, and views (though not triggers or events), causing the object to run with the privileges of the user who invoked it, instead of the definer, which is the default behavior.
To see the permissions the existing definer has, for example if you see DEFINER=`someguy`#`localhost`:
mysql> SHOW GRANTS FOR 'someguy'#'localhost';
You can find the current definer in the definition of the procedure, with SHOW CREATE PROCEDURE procedure_name;.
Piping "SHOW CREATE PROCEDURE foo" into mysql results include the complete procedure definition in a column labeled "Create Procedure". However,
$dbh->selectrow_hashref("SHOW CREATE PROCEDURE foo");
results in $ref->{'Create Procedure'} being undef, with other columns correctly populated.
Both executed on the same machine with the same credentials.
Does anyone know why?
This is what you would see if the user you connect as doesn't have permission to see the procedure. Try using the same user on the command line and I'd guess you will see NULL for the Create Procedure column.
You appear to need select privilege on mysql.proc to see procedure bodies.
I want to store the activity of each session user at very high level into a table.
I wrote a procedure "audit.login_trigger". I have created the schema needed(audit DB and Table). It is some thing like this.
CREATE PROCEDURE audit.login_trigger()
SQL SECURITY DEFINER
BEGIN
INSERT INTO audit.audit_connect (thread_id, user, login_ts)
VALUES (CONNECTION_ID(), USER(), NOW());
END;
I have place this inside "init_connect".
SET GLOBAL init_connect="CALL audit.login_trigger()";
I want this to be executed for every user connection. I gave EXECUTE privileges on this PROCEDURE to root user but when the root user logged in, it is not populating the audit schema as expected. What might went wrong here ?
Thanks in advance.
Since this user is named "root" I wonder if it has super privileges. If it does, then note that init_connect doesn't fire for super users.
I have a stored procedure in MySQL. When I run SHOW PROCEDURE STATUS LIKE 'sp_name' I get some columns that explains the stored procedure.
The definer is set to Definer root#% and Security_type is set to DEFINER. Does this mean that only the root-user can call the stored procedure?
Does this mean that only the root-user can call the stored procedure?
No, it doesn't. Any user with EXECUTE privilege can call this procedure.
From the reference - The SQL SECURITY characteristic can be used to specify whether the routine should be executed using the permissions of the user who creates the routine or the user who invokes it.
CREATE PROCEDURE Syntax.