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
Related
User with db_reader would like to get execute permission on stored procedure that contains INSERT and TRUNCATE statements against existing tables.
Just to see I granted what was requested, but it seems like it doesn't work.
Is such mix of permissions doable?
EDIT: I granted permissions on sp using this:
use [dbName]
GO
GRANT EXECUTE ON [dbo].[spFront_ProcedureName] TO [ABC\serviceAccount]
GO
Granting EXECUTE permission on the Stored Procedure allows the user to call the procedure.
However, depending upon what the procedure does, it may still not do as you expect. Specifically around TRUNCATE, see the info at this link which identifies that additional permission may be needed to use TRUNCATE unless the procedure is carefully crafted.
The specific error message may help identify whether the issue arises from this or if it is from ownership chaining.
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.
I'm currently working on an MVC5, EF6 project and needed a stored procedure for a piece of the project. I've written the stored procedure, and now when I try to use it within my code I get an error saying:
The EXECUTE permission was denied on object ....
Yet when I test the stored procedure in SQL Management Studio it let's me run the stored procedure just fine. I'm not really sure what to do to fix this as I've never come across this before.
First create an executor role and then grant exec permission to this role.Then make your user member of this role.
CREATE ROLE db_executor;
GRANT EXECUTE TO db_executor;
EXEC sp_addrolemember 'db_executor', 'user1'
Hopefully this is enough but in case you still have issue check the below.
The schema owner of SP and underlying objects should be the same for sql chaining permission to work.
Check schema owners by:
select name, USER_NAME(s.principal_id) AS Schema_Owner from sys.schemas s
To change the owner of an schema you can:
ALTER AUTHORIZATION ON SCHEMA::YOUR_SCHEMA TO YOUR_USER;
Examples:
ALTER AUTHORIZATION ON SCHEMA::Claim TO dbo
ALTER AUTHORIZATION ON SCHEMA::datix TO user1;
Finally if within your SP you are truncating a table or changing structure you may want to add WITH EXECUTE AS OWNER in your SP:
ALTER procedure [myProcedure]
WITH EXECUTE AS OWNER
as
truncate table etl.temp
Create a separate user role with access 'Execute' and then assign that to your current user. This is the best solution and helped me.
Please follow this link:
https://stackoverflow.com/a/26871428/6761105
We are building a management app for our system, and one of the app's abilities is to create new databases for new users. This app needs to CREATE DATABASE, RESTORE DATABASE, CREATE USER, grant permissions, etc - so the user needs to have some very strong permissions.
We are contracting these services to an external company and we do not want to give them unrestricted access to our system, we only want them to be able to do what we allow them to do. So we thought about encapsulating the entire process in a stored procedure, granting EXECUTE on this to a specific domain user, and running it with EXECUTE AS 'SA'.
Unfortunately that is not possible - SA is not a database user and when we try to define it as one, we get the error
Msg 15405, Level 16, State 1, Line 1
Cannot use the special principal 'sa'.
We then thought about using DBO and setting up cross-database ownership chaining, but this is all beginning to be a serious headache.
Does anyone know of an elegant way to do this?
This is perfectly possible with module signing.
Create a procedure that executes the elevated code.
Add EXECUTE AS CALLER to the procedure
Create a certificate and private key
Sign the procedure
Drop the private key
Export the certificate
Import the certificate in [master]
Create a login derived from the certificate
Grant the required privileges to the certificate derived login
Note that any alteration to the procedure will invalidate the signature and will require to redo the procedure. Dropping the private key is very important because otherwise the vendor can sign a different procedure and get the elevated permissions on arbitrary code. See Signing an Activated Procedure for an example.
To manage things inside a database, you can use EXECUTE AS OWNER and make sure dbo owns the stored procedure. No problems there
However, CREATE DATABASE etc requires server level permissions. Note: you don't need sysadmin permissions.
With SQL Server 2012 you can use server roles, and GRANT CREATE DATABASE to this server role. For earlier versions, you can grant this directly to the login. Or use dbcreator if your prefer.
If you decide they need to manage logins however, securityadmin has the same effective permissions as sysadmin
create database admin;
GO
alter database admin set trustworthy on
GO
alter authorization on database::admin to [sa]
GO
use admin
GO
create procedure adminProc
with execute as 'dbo'
as
create database test
GO
create login tmp with password = 'tmp', check_policy = off
GO
create user tmp
GO
grant execute on adminProc to tmp
GO
execute as login = 'tmp'
GO
-- This fails
create database test
-- This works
exec adminProc
GO
revert
GO
drop database test
GO
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