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.
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 am logged in my database with a db_owner account. I am trying to grant EXEC permission to another user: MyTestUser. The simple code is:
USE MyDB
GO
GRANT EXEC ON [MyTestUser] TO PUBLIC
The error:
Cannot find the object 'MyTestUser', because it does not exist or you do not have permission
You don't see it in the following picture cause for the sake of privacy but trust me it's there, exactly as MyTestUser
I think you may have mixed up your statement. A GRANT statement usually goes like this:
GRANT <permission> ON <what resource you want to grant access to> TO <who you want to get the access to the resource>
So your statement is saying you want PUBLIC (all users) to have rights to run EXEC statements on MyTestUser. It is expecting MyTestUser to be a function, stored procedure, etc. So if that is a user, it would fail because it can't find something executable called "MyTestUser".
Say you wanted allow to MyTestUser to execute dbo.spMySproc, you would run:
GRANT EXEC ON dbo.spMySProc TO MyTestUser
What is the diffrence between...
execute as user = 'testuser'
AND
execute as login = 'testuser'
I am executing a cross database procedure under these logins and it works with the exececute as login but not the execute as user. It is saying the server principal "testuser" is nt able to access the database "xxx" under the securty context.
When i SELECT SYSTEM_USER after both commands I see that it is set to 'testuser'
execute as login provides impersonation to the entire server, since logins are on a server level. Since users are defined per database, execute as user impersonation applies only to a specific database, which is why you see the error when you cross databases.
The EXECUTE AS can be added to stored procs, functions, triggers, etc.
Example to Execute As:
CREATE PROCEDURE dbo.MyProcedure
WITH EXECUTE AS OWNER
In this case you are impersonating the owner of the module being called.
You can also impersonate SELF, OR the USER creating or altering the module OR...
impersonate CALLER , which will enable to module to take on the permissions of the current user, OR...
impersonate OWNER, which will take on the permission of the owner of the procedure being called OR...
impersonate 'user_name', which will impersonate a specific user OR...
impersonate 'login_name' with will impersonate a specific login.
Setting permission on objects like stored procedures can be accomplished with
GRANT EXECUTE ON <schema>.<procedurename> to <username>;
However, you may also want to grant security rights at both the login and user level.
You will want to determine and grant ONLY the necessary rights
for the objects that require access (such as execution). Consider use of the "EXECUTE AS" capability which enables impersonation of another user
to validate permissions that are required to execute the code WITHOUT having to grant all of the necessary rights to all of the underlying objects (e.g. tables).
MOST of the time, you will only need to grant EXECUTE rights to stored procs and then rights are granted to all objects referenced within the stored proc.
In this way, you do not need to give implicit rights (example: to update data or call additional procs). Ownership chaining handles this for you.
This is especially helpful for dynamic sql or if you need to create elevated security tasks such as CREATE TABLE. EXECUTE AS is a handy tool to consider for these.
This example may help clarify all of this:
--Create a user called NoPrivUser with public access to a database (e.g. dbadb)
USE [master]
GO
CREATE LOGIN [NoPrivUser] WITH PASSWORD=N'ABC5%', DEFAULT_DATABASE=[dbadb], CHECK_EXPIRATION=ON, CHECK_POLICY=ON
GO
USE [DBAdb]
GO
CREATE USER [NoPrivUser] FOR LOGIN [NoPrivUser]
GO
NOTE: CREATOR OR OWNER OF THIS PROCEDURE WILL REQUIRE CREATE TABLE RIGHTS within the target database.
use DBAdb
go
CREATE PROCEDURE dbo.MyProcedure
WITH EXECUTE AS OWNER
AS
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].MyTable') AND type in (N'U'))
CREATE TABLE MyTable (PKid int, column1 char(10))
INSERT INTO MyTable
VALUES (1,'ABCDEF')
GO
GRANT EXEC ON dbo.MyProcedure TO NoPrivUser;
GO
-- Now log into your database server as NoPrivUser and run the following.
use dbadb
go
EXEC dbo.MyProcedure
--(1 row(s) affected)
Now try to select from the new table while logged on as NoPrivuser.
You will get the following:
select * from MyTable
go
Msg 229, Level 14, State 5, Line 1 The SELECT permission was denied on
the object 'MyTable', database 'DBAdb', schema 'dbo'.
That is expected since you only ran the procedure under the security context of Owner while logged on as NoPrivUser.
NoPrivUser as no rights to actually read the table, Just to execute the procedure which creates and inserts the rows.
With the EXECUTE AS clause the stored procedure is run under the context of the object owner. This code successfully creates dbo.MyTable and rows are inserted successfully.
In this example, the user "NoPrivUser" has absolutey no granted rights to modify the table, or read or modify any of the data in this table.
It only takes on the rights needed to complete this specific task coded WITHIN the context of this procedure.
This method of creating stored procedures that can perform tasks that require elevated security rights without permanently assigning those rights come be very useful.
Login scope is at the server level while user scope is at the current database level
http://msdn.microsoft.com/en-us/library/ms181362.aspx
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.
I am looking for a way to have a database user only have rights to execute stored procedures and functions. This needs to be a dynamic setting so that every time i add a stored procedure or function they have rights to it.
Constraints
I cannot change the names of the schema or stored prcedures or functions.
In SQL Server 2005 and newer, you can create a new database role
CREATE ROLE db_executor
and then grant that role the permission to execute - without specifying anything.
GRANT EXECUTE TO db_executor
This role can now execute all stored procedures and function in the database - and it will be able to execute any future stored procedures you add to the database, too!
So now just add this role to your user and you're done:
exec sp_addrolemember #rolename = 'db_executor', #membername = 'your-user-name-here'
PS: of course, you could also grant this permission to just a single user:
GRANT EXECUTE TO your-user-name
This makes management a nightmare, however - so I wouldn't go down that path..