I have an agent job that executes a .dtsx package. It needs to be called from a stored procedure owned by a database user, and used by the app and executes as owner.
Granted
Code:
DECLARE #return_value INT
EXEC #return_value = [dbo].[rscc_drop_off_caller]
SELECT 'Return Value' = #return_value
I gave the user SQLAgentUserRole and confirmed it has execute on sp_start_job.
If I run:
DECLARE #ReturnCode INT;
EXEC #ReturnCode = msdb.dbo.sp_start_job N'RSCC Push CCD To AIM';
PRINT #ReturnCode;
from a window in SSMS, it runs fine.
But if I run:
exec csisql.rscc_drop_off_caller;
it fails with an error:
Msg 229, Level 14, State 5, Procedure sp_start_job, Line 1
The EXECUTE permission was denied on the object 'sp_start_job', database 'msdb', schema 'dbo'.
The 'rscc_drop_off_caller' procedure attempted to return a status of NULL, which is not allowed. A status of 0 will be returned instead.
I even tried to drop and recreate the stored procedure after granting the permission but I get the same error. The stored procedure is pretty simple:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[rscc_drop_off_caller]
WITH EXECUTE AS OWNER
AS
DECLARE #ReturnCode int;
BEGIN
EXEC #ReturnCode = msdb.dbo.sp_start_job N'RSCC Push CCD To AIM';
RETURN (#ReturnCode);
END
Sorry if I provided too much information. I really need to get this working but I'm stumped. Any help would be REALLY appreciated. Thanks in advance.
KT
To summarize: I need to be able to call the agent job from within the stored procedure. That currently fails although calling the job directly (exec...) as the owning user works fine.
Thanks for the help. I resolved the issue. I modified the SP to execute as caller and granted specific permission to that DAimConnUser to execute the stored procedure.
Related
I'm trying to run a stored procedure which starts up a job. When I run it as myself (as a sysadmin), it runs without a hitch, but when I run it as a custom SQL Server user ("SQLAgentUser" -- mapped to a SQL Server login), it gives the error:
EXECUTE permission was denied on the object 'sp_start_job', database 'msdb', schema 'dbo'.
SQLAgentUser is a member of all the following roles in msdb:
SQLAgentOperatorRole
SQLAgentReaderRole
SQLAgentUserRole
In addition, SQLAgentUser has the following explicit permissions granted in MSDB:
GRANT EXECUTE on sp_start_job (and when I look at effective permissions in SSMS, it says it has Execute permissions)
GRANT EXECUTE on sp_stop_job (same as above)
In MyDb (not its actual name), SQLAgentUser has EXECUTE permissions to the sqladm schema, as well as DELETE, INSERT, SELECT, and UPDATE permissions to sqladm.AgentJobsLastRun.
According to everything I found online, this SHOULD be all that's needed, but I'm still getting the error when executing as SQLAgentUser.
Here's the erroring code:
USE [MyDb]
GO
DECLARE #RC int
EXECUTE AS USER = 'SQLAgentUser'
UPDATE [sqladm].[AgentJobsLastRun]
SET RunDate = NULL
WHERE JobName = 'MonthlyJobs'
EXECUTE #RC = [sqladm].[udp_DailyJob]
REVERT
GO
If I comment out, "EXECUTE AS USER = 'SQLAgentUser'," it runs without a hitch.
...and the code inside [sqladm].[udp_DailyJob]:
SET NOCOUNT ON;
-- Insert statements for procedure here
-- First check that the monthly job has run this month (should have run at 2 AM on the first). If not, manually run the job.
DECLARE #AgentJobNameSys nvarchar(128) = N'MonthlyJobs'
DECLARE #LastRunDate datetime = COALESCE((SELECT [RunDate] FROM [sqladm].[AgentJobsLastRun] WHERE JobName = #AgentJobNameSys),DATEADD(month,-1,getdate()))
IF #LastRunDate < DATEFROMPARTS(YEAR(getdate()),MONTH(getdate()),1)
BEGIN
EXEC msdb.dbo.sp_start_job #AgentJobNameSys;
END
Running SQL Server 2019 Developer Edition on my local computer.
Many thanks! :)
I get an error from one of my databases when trying to execute this one
create or alter procedure [dbo].[test_sp]
with execute as owner
as
SELECT SUSER_SNAME()+ ' '+ USER_NAME();
begin
exec master..sp_trace_generateevent #eventid = 82 ,
#userinfo=N'test'
end
GO
exec [dbo].[test_sp]
Error:
Msg 8189, Level 14, State 10, Procedure master..sp_trace_generateevent, Line 1 [Batch Start Line 9]
You do not have permission to run 'SP_TRACE_GENERATEEVENT'.
Granted ALTER TRACE to my user (which returns in SUSER_SNAME()), but it wasn't help
The same script on the second database (same server) works without errors.
What else can it be?
You're trying to run this with EXECUTE AS OWNER, and the owner is a database-level principal and you can't operate outside the current database while impersonating a database-level principal. Switch to EXECUTE AS CALLER (the default) to have the caller's identity used to run the proc in master. eg
create or alter procedure [dbo].[test_sp]
with execute as caller
as
SELECT SUSER_SNAME()+ ' '+ USER_NAME();
begin
exec master..sp_trace_generateevent #eventid = 82, #userinfo = N'test'
end
GO
exec [dbo].[test_sp]
This can be made to work with owner-impersonation by marking the database as TRUSTWORTHY. See: Extending Database Impersonation by Using EXECUTE AS and Guidelines for using the TRUSTWORTHY database setting in SQL Server
I'm trying to create a stored procedure that creates a dB-snapshot for a non privileged user.
The idea is to provide to a normal user a way to create a dB snapshot in order to run queries against it and delete the snapshot when it is done with it.
I thought it would be possible to use the 'with execute as owner" in the procedure declaration. However, I always get the following error:
CREATE DATABASE permission denied in database 'master'.
Here is my code:
-- The user that create the sp has sysadmin right
CREATE OR ALTER PROCEDURE [dbo].[makeSnapshot] WITH EXECUTE AS OWNER
AS
-- just an extract of the code (should test if exist...)
DECLARE #exec NVARCHAR(2000)
set #exec = 'CREATE DATABASE test_dbss1900 ON ( NAME = test, FILENAME =
''C:\\Program Files\\Microsoft SQL Server\\MSSQL14.SQLSERVER2017\\MSSQL\\Data\\test_1900.ss'' ) AS SNAPSHOT OF test';
EXEC (#exec)
GO
-- try to execute it (with any user)
EXEC dbo.[makeSnapshot]
Has anyone an idea how I can come up with a stored proc that will allow a normal user to create a db snapshot?
Thank for any help!
José
I actually found a solution by looking at - http://www.sommarskog.se/grantperm.html#serverlevel (chapter 5.3)
The way was to use certificates
When trying to run a stored procedure, I get the following error:
Msg 102, Level 15, State 1, Line 1
Incorrect syntax near '#CSVPath'.
I'm trying to execute it using the following:
EXEC dbo.ProcessData #CSVPath = 'D:\Data.csv'
My stored procedure starts like this:
ALTER PROCEDURE [dbo].[ProcessDataData]
#CSVPath varchar(MAX) --Path to CSV containing data.
AS
BEGIN
{query}
END
I don't know what I'm doing wrong when passing the parameter value.
Thank you.
Assuming Your proc name has the word data only once, I have just managed this successfully:
create PROCEDURE [dbo].[ProcessData]
#CSVPath varchar(MAX) --Path to CSV containing data. AS BEGIN
select #CSVPath END
EXEC dbo.ProcessData #CSVPath = 'D:\Data.csv'
Output:
D:\Data.csv
First confirm with stored procedure name and use the same SP name so that u will not get this kind of errors
You are executing wrong sp
use below query it will execute
EXEC dbo.ProcessDataData #CSVPath = 'D:\Data.csv'
This is work...your Procedure name is [dbo].[ProcessDataData] and you execute EXEC dbo.ProcessData....please like that execute EXEC dbo.ProcessDataData its work for mee...
ALTER PROCEDURE [dbo].[ProcessDataData]
#CSVPath varchar(MAX) --Path to CSV containing data.
AS
BEGIN
-- Query to execute data
END
EXEC dbo.ProcessDataData #CSVPath = 'D:\Data.csv'
Hope Its Work !!!
Happy Coding !!!
Try it, may be it works for you;
EXEC dbo.ProcessData 'D:\Data.csv'
It'll auto map your data to the parameter: #CSVPath. Otherwise, may be the issue was in your query. If issue still exists, share your complete StoredProcedure for better judgment and solution.
I'm using SQL Server 2014.
I have granted EXECUTE on a stored procedure to a user account, but when the sp is run, I get both a result and an error. This is from SSMS, with "Results to Text" selected:
set nocount on
use trx_d
go
select specific_name
from information_schema.routines
where routine_type = 'PROCEDURE'
and specific_name = 'proc_plan_get_count';
go
exec dbo.proc_plan_get_count 225, 2016;
go
specific_name
----------------------------------
proc_plan_get_count
status_code status_count
-------------------- ------------
Approved 1
Msg 15151, Level 16, State 1, Procedure proc_plan_get_count, Line 25
Cannot find the object 'proc_plan_get_count', because it does not exist or you do not have permission.
I tried dropping and recreating the sp (which just contains a SELECT statement with a WHERE clause reflecting the parameters being passed in). I thought that might clear the cobwebs, since when I tried to create a new, simple procedure I had no problems. The drop & create had no effect, with the same behavior above appearing.
I changed the contents of the sp to avoid any table references, ran it and I received no error. Putting back in the SELECT stmt caused the issue to re-surface. This user account is in the db_datareader role, though (and you can see in the output above that it is successfully reading the table).
Then I tried just recreating the procedure under a new name (I added a "2" at the end), and when running it I received no errors.
I am thoroughly confused, thanks for any help on figuring this out,
--=Chuck
Being new to SQL Server, this one escaped me for a bit. Here's the gist of the code when I request to modify it through SSMS:
USE [trx_d]
GO
/****** Object: StoredProcedure [dbo].[proc_plan_get_count] Script Date: 1/25/2016 12:36:49 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[proc_plan_get_count]
-- Add the parameters for the stored procedure here
#EmployeeId int = 0,
#PlanYear int = 0
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
SELECT stdcode as status_code, COUNT(*) as status_count
FROM **********
WHERE yr = #PlanYear AND
empnum = #EmployeeId
GROUP BY stdcode
END
GRANT EXEC ON [dbo].proc_plan_get_count TO *****
So, since there's no GO after the END keyword, that GRANT stmt is actually part of the source code, and was the source of the error upon sp execution.
Why did we hit it now? We were switching to a new database login, and while the new login looks to have all of the same privileges as the old login, there must be some other privilege that the old login has which doesn't balk at the GRANT EXEC step. It throws a warning instead of an error:
status_code status_count
-------------------- ------------
Approved 3
Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.