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;.
Related
In MSSQL I'm used to using roles for security and permissions but in MySQL/MariaDB it seems that users are a staple that you can't really get around. One specific case I'm wondering about is a DEFINER on a view or stored procedure. I essentially can't script that object without knowing what user it should run as ahead of time, in my case. Is there a way to define it with a specific role instead of a user?
You can use
CREATE DEFINER=`your role` PROCEDURE / FUNCTION ()
SQL SECURITY DEFINER -- that's the default
begin
....
end
'Your role' must have execute permission for the procedure und all the privileges needed inside the procedure.
In simplification, I have a MySQL procedure get_data(), which selects filtered data for users. Customized filter conditions are stored in database table. Procedure get_data() should gets conditions for current user and select only his data by adding a WHERE clause.
But when I defined procedure with SQL SECURITY DEFINER characteristic, detection current user (invoker) in procedure body is not possible because function current_user() returns definer's name, and when I defined procedure with SQL SECURITY INVOKER characteristic, the procedure failed because invoker haven't SELECT privileges on source table.
Is it possible to create a procedure in MySQL, which selects customized data for user from table not accessible for user?
Currently, I have defined views (one for each user), but the maintenance of this in a situation where conditions in queries are constantly changing is hard.
Have you tried using user() instead of current_user()?
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.
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.
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.