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>
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.
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)
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.
Requirement:
User A can log in to SS instance, but only has access to database X. User A has no other access to any objects.
database X has a stored_proc called "sp_exec_dml" which takes a DML string and executes it. This stored proc would(should?) run as the owner X.
does database X, or the stored procedure ""sp_exec_dml" then need access to other dbs/objects.
for example
user A executes
exec x..sp_exec_dml N"update z..table set ..................."
I hope this makes sense. I come from an Oracle background so exactly how permissions are granted and who the grantees can be is confusing.
do databases or stored procedures have access granted to them
thanks
According to the MSDN : (URL : https://msdn.microsoft.com/en-US/library/ms345484.aspx )
To grant permissions on a stored procedure
In Object Explorer, connect to an instance of Database Engine and then expand that instance.
Expand Databases, expand the database in which the procedure belongs, and then expand Programmability.
Expand Stored Procedures, right-click the procedure to grant permissions on, and then click Properties.
From Stored Procedure Properties, select the Permissions page.
To grant permissions to a user, database role, or application role, click Search.
In Select Users or Roles, click Object Types to add or clear the users and roles you want.
Click Browse to display the list of users or roles. Select the users or roles to whom permissions should be granted.
In the Explicit Permissions grid, select the permissions to grant to the specified user or role. For a description of the permissions,
see Permissions (Database Engine).
Selecting Grant indicates the grantee will be given the specified
permission. Selecting Grant With indicates that the grantee will also
be able to grant the specified permission to other principals.
This link also explains few concepts :
(URL : https://dba.stackexchange.com/questions/6878/sql-server-stored-procedure-permissions )
Stored procedures take advantage of ownership chaining to provide
access to data so that users do not need to have explicit permission
to access database objects. An ownership chain exists when objects
that access each other sequentially are owned by the same user. For
example, a stored procedure can call other stored procedures, or a
stored procedure can access multiple tables. If all objects in the
chain of execution have the same owner, then SQL Server only checks
the EXECUTE permission for the caller, not the caller's permissions on
other objects. Therefore you need to grant only EXECUTE permissions on
stored procedures; you can revoke or deny all permissions on the
underlying tables.
If database X has "table" in
exec x..sp_exec_dml N"update z..table set ..................."
then the user should have access.
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.