I'm trying to allow a user to view SQL Server trace data from a .trc file without giving them ALTER TRACE permissions (SQL Server 2008 R2). So I've wrapped it up in a stored procedure, using my sysadmin account:
CREATE PROCEDURE test_trace
as
SELECT * FROM FN_TRACE_GETTABLE(N'C:\temp\trace1.trc', 1)
If I execute this stored procedure using my sysadmin account, it runs fine as expected. If I try to run this under the domain1\user1 account, it does not run giving an error of "You do not have permission to run 'FN_TRACE_GETTABLE'". This is again expected.
So now I want to let domain1\user1 run the stored procedure, so I change the stored procedure to execute under a sysadmin account:
CREATE PROCEDURE test_trace
WITH EXECUTE AS 'domain1\sysadmin1'
as
SELECT * FROM FN_TRACE_GETTABLE(N'C:\temp\trace1.trc', 1)
Now when I execute the stored procedure, I get "You do not have permission to run 'FN_TRACE_GETTABLE'" regardless of the account I execute it under! I was expecting to be able to execute it both under the domain1\user1 and domain1\sysadmin1 accounts.
Could anybody please help with what I've missed? My goal is to allow domain1\user1 to read the trace1.trc file without giving them ALTER TRACE permissions.
You need to use code signing to elevate privileges in a controlled manner. While in an EXECUTE AS procedure context you are sandboxed and cannot leverage a server level priviledge (such as trace related permissions), read Extending Database Impersonation by Using EXECUTE AS. Code signing is the proper solution to this problem as well. See a full example here.
According to the documentation you can only specify a (database) username in execute as for stored procedures. Still I think this should normally work, but please alter the SP with the sysadmin account and specify EXECUTE AS SELF instead of the user name.
If that still does not work, try giving the executing user read rights on the trace file, maybe the server ignores the execute as for the file access (which I would consider as a bug).
Copy&paste the path into a new explorer window and if it gives an error, there's your problem. Took me a while to figure out why SQL Server said the "sa" account didn't have permissions that it did have.
Related
I've been struggling to get the total capacity of a disk drive where SQL Server is installed; I know I can achieve that with sys.dm_os_volume_stats or xp_cmdshell but to run the query you need some permissions like VIEW SERVER STATE or ALTER permission.
Is there a way for a normal user to get the full capacity of the disk without granting special permissions?
You can Execute any Stored Procedure or Table Value Function as a specific caller :
CREATE PROCEDURE dbo.MyProcedure
WITH EXECUTE AS 'domain\user'
AS
...
More info in StackOverflow
More info in MSDN
Also, If you got a Certificate problem :
Signing Stored Procedures with a Certificate
I need to allow a limited number of users to run a very explicit set of traces on a production server with windows authentication only where the owner of the procedure has ALTER TRACE but the intended developers do not. I created a stored procedure with EXECUTE AS OWNER that sets the fields, filters and schedule needed to run the trace, imports results to a table and returns the results set. I must avoid giving users ALTER TRACE but haven’t been able to get over this hump. I hope to avoid using a SQL agent task but have run out of ideas.
Maybe I'm getting this wrong, but... I have a SQL Server 2000 database with a stored procedure that is owned by DBO. This stored procedure is calling sp_grantdbaccess, which can be run by DBO, according to MS documentation. and I'm running a Windows user that belongs to a database role that has execute permission on this stored procedure.
If I understand ownership chaining correctly (which I obviously don't), I should be able to run this stored procedure, since it is run with impersonation as DBO.
But alas, it is telling me that the user doesn't have permission to run sp_grantdbaccess.
What can I do to solve this?
I have restored a 2005 Database to a new 2008 R2 DB Server. I have created a new user called "gatekeeper"
However this user does not have access to the list of stored procedure in the database.
In a reporting application before running the query the report program is running the following procedure...
exec [Timesheet]..sp_procedures_rowset N'mp_GetTimesheetToPrint',1,N'dbo'
When run under gatekeeper user this returns no rows. However when run as sa it returns the procedure.
What is the minimum permission I need to give to gatekeeper for this procedure to work properly. It seems to be a problem with all system objects, none of them fail to run or give permission errors, they just return no results or subsets of the results.
Really struggling with this. Thanks in advance
Regards
Phil
I am honestly a bit confused by your description, so please let me know if I am off base here. You can try this below. It will grant execute access to all stored procedures. If you only need gatekeeper to have access to the one stored procedure, then just grant execute on that stored procedure. If the stored procedure is accessing data from other databases, you may need to grant permissions on the tables and such that it is accessing outside of its database.
CREATE ROLE db_executor
GRANT EXECUTE TO db_executor
EXEC sp_addrolemember 'db_executor', 'gatekeeper'
I recently did an import of database from a sql server 2000 database to a sql server 2005 database. I've gone through and setup what I thought were the same login credentials and owner permissions that I had previously setup in my old database.
All of the code base I'm working has stored procedures listed simply by stored procedure name.
In order to make sure I have the proper logins created, I am logging into the SQL Server Management studio with the connection information my application is using (i.e. using the username "licensemgr" and it's associated password). I can see all the tables, stored procedures, etc... in my database when I log in with combination. When I try to run a stored procedure, Sql Server Management Studio uses the following syntax to execute it:
EXEC: #return_value = [licensemgr].[Stored_Procedure_Name]
and it executes without error.
If I try to remove the [licensemgr]. from before the [Stored_Procedure_Name], however I get the error "Cannot find stored procedure: Stored_Procedure_Name". This is the same error I get when running my application off this database. I changed one stored procedure call in my application to have "licensemgr." in front of the stored procedure name and that seemed to correct the problem, however, I don't want to do that for each and every stored procedure call in my application. I am therefore wondering what type of setup / permissions type issue I might be missing in my SQL Server instance so that even when I'm logged into the database as licensemgr, I cannot see the stored procedure which is in the schema "licensemgr".
In SQL server 2000 the [licensemgr] referred to the owner of the table. So when you are logged in as [licensemgr] you do not need the prefix.
In SQL Server 2005 this has been changed to the schema, therefore it must be specified. See:
http://msdn.microsoft.com/en-us/library/ms190387.aspx
EDIT
There are two things that you need to watch out for:
If the user is in the sysadmin role, he will always default to the dbo schema, therefore you need to prefix
If your user needs to run code that is in different schemas you will need to prefix
If none of the two above it should work by setting the default schema for the user
When you created your user, did you specify DEFAULT_SCHEMA?
CREATE USER ... WITH DEFAULT_SCHEMA = "licensemgr"
If not, you may need to use ALTER USER to fix this for your user in the new system.