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!
Related
Am trying to execute a procedure on teradata and it seems to be I don't have privileges to execute the procedure, even the SP owner isn't able to grant access to me.
Is there other way around to get access of that procedure?
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 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.
I have created a stored procedure using SQL Server Management studio.
I am able to create it but if I tryto right click on the stored procedure and execute it, I am getting permission denied error# 229.
I have administrator rights. How can I execute this procedure.
if you are really connecting as sa this should not happen, if you are not, could be that your user does not really have all the rights.
It is also difficult to understand the problem without seeing the body of the stored in case you are doing anything special in there.
at this link anyway: http://www.sqlservercentral.com/Forums/Topic463688-146-1.aspx somebody was discussing the same error and there are some SQL commands scrolling down the page where some people claim to have fixed the issue.
Are you sure that you have sufficient permissions?
Error 229 means that you don't.
Your user needs at least EXECUTE permissions for the stored procedure:
Stored Procedure and Permissions - Is EXECUTE enough?
Here's how you can check if you have the permission:
MS SQL Server: Check to see if a user can execute a stored procedure
Verify that you didn't add your user to any of the deny roles, like db_denydatareader.
Use this to add execute privillages to your SQL Login:
GRANT EXECUTE ON SPNAME TO UserName;
GO
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.