I'm trying to allow a stored procedure for a user, but struggling to get it right. Hopefully I'm on the right track, thanks for the help.
GO
Alter role ReportDeveloper
Add sp_GetActiveProductInfo
GRANT EXECUTE ON ReportDeveloper TO employee_usr;
Grant permission to database role not user.
USE DB_NAME;
GRANT EXECUTE ON sp_GetActiveProductInfo TO ReportDeveloper;
GO
It rather should be like below per Documentation
USE DB_NAME;
GRANT EXECUTE ON OBJECT::sp_GetActiveProductInfo
TO employee_usr;
GO
You can do it as ;
USE databse;
GRANT EXECUTE ON sp_GetActiveProductInfo TO employee_usr;
GO
If you add this user to a Role you will Grant the permission to the Role where your user is member in :
USE databse;
GRANT EXECUTE ON sp_GetActiveProductInfo TO ReportDeveloper;
GO
Related
Its a newbie question but still I am trying to grant create user permission to sysadmin role from the accountAdmin role so that I can create users in the sysadmin role.
The statement I am trying to execute is:
grant create user to role sysadmin;
Error
SQL compilation error: syntax error line 1 at position 18 unexpected 'to'.
What's the exact statement to achieve this?
I tried googling but haven't found any exact query statement in a long time, so posting it here.
Grant create user on account to role role_name ;
Please note that this statement has to be submitted as an ACCOUNTADMIN
https://docs.snowflake.com/en/sql-reference/sql/grant-privilege.html
You could also choose to use the WITH GRANT OPTION which allows the grantee to regrant the role to other users.
Grant create user on account to role role_name WITH GRANT OPTION;
Is there a way I can grant truncate permission to a user without altering privileges in SQL Server?
The minimum permission required is ALTER on table_name. TRUNCATE TABLE permissions default to the table owner, members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and are not transferable. However, you can incorporate the TRUNCATE TABLE statement within a module, such as a stored procedure, and grant appropriate permissions to the module using the EXECUTE AS clause.
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT user_name();
Source
You can go through this official documentation.
Create a test Login and User id then grant it execute permission on the stored procedure Truncate_Table_Loner. This id will be used to perform the truncate.
-- Grant Execute Permission
-- Setup ID on Database with Connect permission
USE master
GO
CREATE LOGIN [test_user_id] WITH PASSWORD = 'JustConnect123';
GO
USE TestSQL
GO
CREATE USER [test_user_id] FOR LOGIN [test_user_id];
GO
-- Grant Permission
GRANT EXECUTE ON dbo.Truncate_Table_Loner TO [test_user_id];
GO
How do I Grant drop permission of stored procedure in SQL Server to user via script?
I tried the following, but it does not work
use XpressFeed_Dev
GRANT DROP ON procedure::getPartyDuns TO "INT\svc-w-corerefdata-de";
use XpressFeed_Dev
ALTER AUTHORIZATION ON [getPartyDuns] TO "INT\svc-w-corerefdata-de";
Permissions
Requires CONTROL permission on the procedure, or ALTER permission on
the schema to which the procedure belongs, or membership in the
db_ddladmin fixed server role.
DROP PROCEDURE (Transact-SQL)
So the minimum permission of all mentioned above is control on a procedure because after it will be dropped the user will have no additional permissions
GRANT CONTROL ON object::getPartyDuns TO [INT\svc-w-corerefdata-de];
You must specify schema before the procedure name - like this:
GRANT DROP ON procedure::XpressFeed_Dev.getPartyDuns TO [INT\svc-w-corerefdata-de];
ALTER AUTHORIZATION ON XpressFeed_Dev.[getPartyDuns] TO [INT\svc-w-corerefdata-de];
I want a database user to have ALTER and EXECUTE permissions to a stored procedure. Do I need to grant those separately, or does granting ALTER allow the user to EXECUTE also?
e.g.
GRANT ALTER ON [STOREDPROC] TO [SP_USER];
GRANT EXECUTE ON [STOREDPROC] TO [SP_USER];
or just:
GRANT ALTER ON [STOREDPROC] TO [SP_USER];
(does ALTER imply EXECUTE?)
Thanks!
The short answer is: no, ALTER does not imply EXECUTE.
Slightly longer answer: there's a chart that says what permissions imply other permissions. Check it out!
https://msdn.microsoft.com/en-us/library/ms188371.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.