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?
Related
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 have a stored procedure set up in DATABASE1 that among other things makes a call to a stored procedure call sp_start_job (this is a stored procedure in the msdb database that will fire off an agent job).
I have created a proxy login and mapped this login to user accounts in msdb and DATABASE1 databases.
In my original stored procedure, I am using EXEC as proxylogin. This proxy user has rights to execute this procedure and in the msdb database can execute the sp_start_job procedure and is additionally a member of the SqlAgentOperator,SqlAgentUser, and SqlAgentReader Roles. I have also given the user in DATABASE1 AND msdb authenicate permissions.
The idea is that any user that can execute the original procedure will actually run it under the proxylogin's credentials so I do not have to assign these permissions out. I am still running into permission error, does anyone have insight into this problem?
We got around this by turning cross database ownership chaining on
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 want to create a stored procedure to perform a bulk insert so a user I grant access to the stored procedure can run it without any other permissions.
Is there any way I can grant "ADMINISTER BULK OPERATIONS" to the stored procedure so I don't have to grant server wide bulk op permissions to the user?
Is there any other solution?
I am using SQL Server 2005.
You could modify the stored procedure to use "EXECUTE AS" to have it run under a different context.
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.