I have a function named schema.func, I want to give a permission what execute schema.func to the user.
I try to use
GRANT EXECUTE ON schema.func to my_user;
but it is not working. When I perform this function it throws the error:
permission denied for schema ex
I know I can use GRANT USAGE ON SCHEMA, but this is not what I want, I just need permissions for specific functions, not all functions in the schema.
Can I do that?
First, you should allow my_user to access the other schema:
GRANT USAGE ON SCHEMA my_schema TO my_user;
This allows the execution of functions but not the access to tables. So, if my_user executes the function, it still produces an access error, if the function accesses tables etc. in my_schema. To avoid this, you may define your function as security definer:
ALTER FUNCTION my_schema.my_function(...) SECURITY DEFINER SET search_path = public;
Edit: Writing SECURITY DEFINER Functions Safely also points a way to give execute permission to specific users:
REVOKE ALL ON FUNCTION my_schema.my_function(...) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION my_schema.my_function(...) TO my_user;
Please also note the hints on setting the search_path in this section.
As per PostregSQL documentation
GRANT
The FUNCTION syntax works for plain functions, aggregate functions, and window functions, but not for procedures; use PROCEDURE for those. Alternatively, use ROUTINE to refer to a function, aggregate function, window function, or procedure regardless of its precise type.
...
ALL FUNCTIONS also affects aggregate and window functions, but not procedures, again just like the specific-object GRANT command. Use ALL ROUTINES to include procedures.
try:
GRANT EXECUTE ON ROUTINE my_schema.my_function(text) TO my_user;
assuming that your function signature is something like:
my_schema.my_function(my_par text)
Related
I want to grant TRIGGERS, FUNCTIONS and PROCEDURES to a role. I have the code to do it with procedure but with triggers and functions it not work.
create role Level1;
grant execute any trigger to Level1;
grant execute any procedure to Level1;
User owns tables, functions and procedures. That user created a role and wanted to grant execute on various objects to the role.
for triggers, it doesn't make sense - they fire upon certain action on the table they are created on. Therefore, you'd grant privileges on the table, not on the trigger
for functions and procedures, you'd grant execute privilege on exact functions and procedures (not for all of them in a single statement), e.g.
grant execute on p_insert_student to level1;
grant execute on f_average_marks to level1;
What you posted (grant execute any procedure) is a system privilege; that's kind of dangerous; are you sure you want to let level1 execute absolutely any procedure within the database?
Also, there's no separate grant for functions; in this context, they are considered to be procedures so execute any procedure affects functions as well.
Is there any syntax available in the grant command that would allow something equivalent to
Use [SomeOtherDatabase]
grant execute to [domain\UserLogin]
What I'm hoping to do might look something like this:
grant execute On [SomeOtherDatabase] to [domain\UserLogin]
Which of course does not work...
NOTE:
I am aware of the syntax
grant execute on [Something] to [domain\UserLogin],
but in this form, [something] must be an individual database object, (procedure/function), as in
grant execute on [database.Schema.Procedure] to [domain\UserLogin],
not all objects in the database. you can't do
grant execute on [Database] to [domain\UserLogin]
and apply the grant for every object in the database.
Using postgresql 9.6
I enabled pgcrypto using create extension pgcrypto using the postgres user.
Now i want to grant execute rights to my other db user. Unfortunately i am not able to do it. Is this possible or do you have to be a superuser to use the digest function from pgcrypto.
postgres=# GRANT EXECUTE ON FUNCTION digest TO another_user;
ERROR: syntax error at or near "digest"
LINE 1: GRANT EXECUTE ON FUNCTION digest TO another_user;
Using the answer below, I was able to successfully grant permission to execute the function. However another_user cannot execute the function. Are there other permissions that i need in order to execute this function using another_user?
another_user=> SELECT digest('whatisgoingon'::text, 'sha256'::text);
ERROR: function digest(text, text) does not exist
LINE 1: SELECT digest('whatisgoingon'::text, 'sha256'::text);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
Even though when i check permissions for the user i get back that i have permissions.
postgres=# select has_function_privilege('another_user', 'digest(text, text)', 'execute');
has_function_privilege
------------------------
t
(1 row)
Thanks
Postgres supports overloading, i.e. multiple functions with the same name but different argument lists.
When calling the function in SQL, it figures out which version you meant based on the number of parameters and their types. But when referencing the function in a DDL command (DROP, ALTER, GRANT, etc.), you need to specify exactly which version you meant, by including a list of argument types after the function name.
This is quite relevant in the case of digest, because there are actually two versions, and you need to make it clear which one you're talking about. So either:
GRANT EXECUTE ON FUNCTION digest(text,text) TO another_user
...or:
GRANT EXECUTE ON FUNCTION digest(bytea,text) TO another_user
(...or both.)
As of Postgres 10, you're allowed to omit the argument list when the function is not overloaded. This doesn't help you much in the case of digest, but at least you get a more informative error message:
postgres=# GRANT EXECUTE ON FUNCTION digest TO another_user;
ERROR: function name "digest" is not unique
HINT: Specify the argument list to select the function unambiguously.
As for your follow-up question regarding the function does not exist error, try schema-qualifying the function name, e.g. SELECT my_schema.digest(...).
If that works, it's a search path issue. You can either continue calling it with an explicit schema name, or update your search_path.
If it responds with ERROR: permission denied for schema my_schema, then you just need to GRANT USAGE ON SCHEMA my_schema TO another_user.
If it still says function my_schema.digest(text, text) does not exist, then you've probably connected to the wrong database by mistake.
I have create a role in my SQL 2008r2 and I now I need to assign number of securables to it (like stored procedures and views).
Is there any TSQL command in order to do that?
Please excuse my expressions (in case there are not the right one) in this case.
I don't know if I'm using the right one.
For Stored Procedures and scalar-valued functions
GRANT EXECUTE ON [dbo].[<Object>] TO <Role>
For Tables, views, and table-valued functions. You can specify any or all of the options used in this example.
GRANT SELECT,INSERT,UPDATE,DELETE ON [dbo].[<TABLE>] TO <Role>
Additionally, you can deny and revoke
DENY EXECUTE ON [dbo].[<Object>] TO <Role>
REVOKE EXECUTE ON [dbo].[<Object>] TO <Role>
Does the following command effectively give the user, "MyUser," permission to execute ALL stored procedures in the database?
GRANT EXECUTE TO [MyDomain\MyUser]
SQL Server 2008 and Above:
/* CREATE A NEW ROLE */
CREATE ROLE db_executor
/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor
For just a user (not a role):
USE [DBName]
GO
GRANT EXECUTE TO [user]
SQL Server 2005 introduced the ability to grant database execute permissions to a database principle, as you've described:
GRANT EXECUTE TO [MyDomain\MyUser]
That will grant permission at the database scope, which implicitly includes all stored procedures in all schemas. This means that you don't have to explicitly grant permissions per stored procedure.
You can also restrict by granting schema execute permissions if you want to be more granular:
GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]
In addition to the answers above, I'd like to add:
You might want to grant this to a role instead, and then assign the role to the user(s).
Suppose you have created a role myAppRights via
CREATE ROLE [myAppRights]
then you can give execute rights via
GRANT EXECUTE TO [myAppRights]
to that role.
Or, if you want to do it on schema level:
GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]
also works (in this example, the role myAppRights will have execute rights on all elements of schema dbo afterwards).
This way, you only have to do it once and can assign/revoke all related application rights easily to/from a user if you need to change that later on - especially useful if you want to create more complex access profiles.
Note: If you grant a role to a schema, that affects also elements you will have created later - this might be beneficial or not depending on the design you intended, so keep that in mind.