I have a database where all access is controlled by stored procedures. The DBA would like to avoid giving users direct read/write access to the underlying tables, which I can understand. Hence all updating and selecting of data is done via stored procedures. Basically he has created one role that has EXECUTE permissions to all the stored procedures in the database and given users that role.
The problem is that one of the stored procedures dynamically builds a SQl Query and executes it via "Execute sp_Executesql". Without going into great detail the query is built dynamically because it changes significantly depending on many user input parameters. The stored procedure in question is only a SELECT sql statement however I am finding that just giving the stored procedure EXECUTE permission is not enough. The underlying tables referenced within the stored procedure that make use of "Execute sp_Executesql" need to have been given "datareader" access or else the stored procedure fails.
Any thoughts on how to correct this? I really wanted to restrict access to the tables to only stored procedures, but I need to find a way to work around the stored procedures that make use of "Execute sp_Executesq"l. Thank you.
In the wrapper proc you can use EXECUTE AS OWNER or EXECUTE AS SomeuserWithNoLogin
This will change the login context for the duration of the stored proc which includes sp_executesql.
If you use OWNER, it will work because you're already using ownership chaining.
If your DBA (good man!) does not want you running as dbo, then set up a user that has full read but no rights. EXECUTE AS <user> requires an entry is sys.database_principals
Like this:
CREATE USER SomeuserWithNoLogin WITH WITHOUT LOGIN
EXEC sp_addrolemember 'db_datareader', 'SomeuserWithNoLogin'
For more info, see EXECUTE AS Clause on MSDN and CREATE PROCEDURE
The real problem is that sp_Executesql is in the master database, not necessarily the database your working in. Your DBA has to give execute sp_Executesql permission to the calling procedure. Than anyone who has permission to call that procedure will be able to run the sp_Executesql.
Related
I have created a procedure in different database than the user used to create it,
The user I used to create the procedure is like 'vbhas' and the database it is created is like 'IFSRD', when I login as 'vbhas' and try to execute the proc it gives the error, could you please let me know how to modify the execute access so that I will be able to execute this procedure successfully?
Thanks
You have to add the SECURITY option. Depending on the SQL in the SP and your needs this might be SECURITY CREATOR|OWNER|INVOKER instead of the default DEFINER.
You should read the manuals for details
Thanks dnoeth...
Got to know that Teradata gives permissions at database level, so now I created the procedure in the database which has execute permissions to all objects.
I need to restrict user access to SELECT, INSERT, UPDATE and DELETE, so that user should manage data only using stored procedures I provide.
So, for instance
SELECT * FROM Table1
should return
The SELECT permission was denied on the object 'Table1'
however, if there is stored procedure SelectTable1 defined as
CREATE PROCEDURE SelectTable1
AS
BEGIN
SELECT * FROM Table1
END
(the real one contains filtering and parameters, so it is not meaningless, like the one above)
user should execute it successfully and get the resultset.
But obviously, I have no success implementing this set of permissions. Can anybody point me to some specific tutorial? MSDN was not very helpful.
Database is SQL Server 2012 and all objects (tables and stored procedures) are in custom schema.
You can do it using GRANT EXEC either on specific procedures or on schemas or on a database.
The following example grants EXECUTE permission on stored procedure
HumanResources.uspUpdateEmployeeHireInfo to an application role called
Recruiting11.
USE AdventureWorks2012;
GRANT EXECUTE ON OBJECT::HumanResources.uspUpdateEmployeeHireInfo
TO Recruiting11;
GO
Thanks to Igor I've got to the right MSDN page, and followed rights links.
However, using ownership chains suggested was too complicated for me, so I used
WITH EXECUTE AS OWNER
on my stored procedures and that works very good. When I log on using restricted user I see only procedures, no tables at all and I can execute procedures, but not even select from tables.
Also, I want to mention this concept is very similar to setuid and thus was familiar to me.
I mark Igors reply as answer, because ownership chains seem to be more generic way, just wanted to share info I found.
Why can't i execute a stored procedure which contains Dynamic SQL with non SP owner user?
I can execute it succesfully with the SP owner user, but other users can't.
Nevertheless, i have granted permissions on that SP.
Everything works right while that SP has no Dynamic SQL.
I am using Sybase ASE 15.0.3
I've got it!
When there is Dynamic SQL in the SP, also is required to change the execution mode to "dynamic"
sp_procxmode sp_name, "dynamic"
in order to allow non SP owner users to execute successfully that SP.
To execute a stored procedure the user needs to have access to all tables, views, etc. that might be on it, whether in the normal code or in the dynamic code!
I want to set a readony permission to a database user.
This user should have permission to execute stored procedures
But this user should not have permission to update or inser or alter anything in database through these stored procedures or through any methord
can anyone help please
Simply don't grant permission on the stored procs that change data.
Otherwise, you could use triggers on the tables to check, but that's a bit silly compared to using permissions correctly
Note: ownership chaining means that permissions on tables won't be checked, even DENY, so this won't work.
Yes. Set the EXECUTE permission for that user, then they'll only be able to execute the Stored Procedures in your database.
GRANT EXECUTE ON dbo.storedprocedurename TO SQLUSERNAME;
You'll need to set the permissions on a procedure by procedure basis. Give them permission to stored procedures that select, and don't give them permission to the stored procedures that do updates or inserts.The best way is to setup roles, and add the users to the roles.
This is pretty flexible and you can use it to restrict exactly what uses can do. For example, it may actually be okay for them to update a table as long as they do it through a certain stored procedure. To do this you can deny them all permission to that table, but grant them permission to execute the stored proc.
give execute permission on the proc and make sure the user doesn't have write access to the tables used by the proc. Check if he is not member of the db_datawriter roled.
If you want to be 100% sure, add the user to the db_denydatawriter role
I wish to grant a stored procedure read access to a table in SQL Server 2008 R2
I will then grant a user access only to the stored procedure, not to the table itself.
How do I do this?
Grant EXEC access to the single stored procedure and no permissions to the table.
Grant EXECUTE On [SpName] To [Principal]
There is no such concept as a read permissions to a table for a stored procedure. Stored procedure permissions are separate from other objects. If a user has permission to run a stored procedure, they can run it no matter what it does, even if they don't have permission to the underlying objects.
The following article is a very detailed look at several different methods for granting permissions using stored procedures. It's definitely worth a read.
http://www.sommarskog.se/grantperm.html
Most of the time, ownership chaining will take care of permissions problems. As long as the stored procedure and the underlying table have the same owner, the user only needs permission to EXECUTE the stored procedure.
In a comment to another answer, you mention that the stored procedure is in a different database from the table. You might look at module signing as a method for allowing access only through the stored procedure. Another alternative, if possible, is to create the stored procedure in the same database as the table, then grant access to users in the other database. That way, ownership chaining will take effect.