I have a user that have grants to execute one procedure into one SQL Server 2008 R2 database.
This procedure connects to other databases but execution fails for this user, because it do not see this other databases.
How can I have a user with execution grants of some procedures in a single database where this procedures connects to other databases?
Thank you.
The login used for execution needs permission to do what your procedure does on the target database(s) the procedure is working on.
Related
I am configuring the database accounts for some new users. I have come up with the following solution which is 99% of the way to getting the accounts to work but I have hit a problem which I cannot resolve.
Firstly, I created a new login with SQL Server authentication and then gave them the EXECUTE permission to all stored procedures. This allows them to run them all but they cannot view the code and they cannot view the database tables.
Inside the stored procedures I added the following:
WITH EXEC AS OWNER
This allowed the stored procedures to run as the default account we normally use and this has the role of db_owner. This allows the new users to run all the stored procedures and it works great until I hit the following problem:
Some of the stored procedures (all of which are using dynamic SQL) call some synonyms which link to tables in two other databases (history and a data mart database). This gives me the following error:
The server principal "{username}" is not able to access the database "{database name}" under the current security context.
The account which I am using in the WITH EXEC AS is the db_owner of all three databases I am working with.
What can I do to resolve this problem? Many thanks
EXECUTE AS Owner is a database sandbox. Think about it, it has to be. Otherwise a database administrator can issue and EXECUTE AS USER = 'somesystemadmin' and elevate himself to an instance level administrator. The details are described in Extending Database Impersonation by Using EXECUTE AS:
when impersonating a principal by using the EXECUTE AS USER statement, or within a database-scoped module by using the EXECUTE AS clause, the scope of impersonation is restricted to the database by default. This means that references to objects outside the scope of the database will return an error.
The solution is simple: sign the procedure. See Call a procedure in another database from an activated procedure for an example. Read more at Module Signing and Signing Stored Procedures in SQL Server.
Problem
I have a SQL Server login that is allowed to create stored procedures, but not execute them. I cannot use another login to grant execute so I am looking for an alternative way to either run the code in the sp or to grant these permissions.
The EXECUTE permission was denied on the object 'sp_mystoredprocedurename', database 'mydatabasename', schema 'dbo'.
The user cannot grant execute to itself
Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.
Background
We have a Windows software application, written in Powerbuilder, that creates and updates the SQL Server database it works on itself.
On first startup the application prompts for a database admin login which it uses 1 time (we don't store this information) to create the database and a login. The login is given db_ddladmin, db_datareader and db_datawriter permissions. We currently have hundreds of these applications and databases running on servers managed by us, but also on our customers' own servers.
For this reason I would do anything to prevent the need to ask the user for a db admin login again so I can grant the execute permissions, which would be the easiest way... Downgrading all servers to SQL Server 2000 is of course also not an option :)
The stored procedure I am trying to implement is a "getnewid" method. Currently my Powerbuilder code uses multiple embedded TSQL statements to achieve this but because of network performance issues I would like to move these to a single stored procedure.
Does this help ?
CREATE ROLE db_executer
GRANT EXECUTE to db_executer
EXEC sp_addrolemember N'db_executer', N'<username>'
Try this.
GRANT EXECUTE ON sp_OACreate to UserLogin
GO
I have a SQL Server 2005 database and I need to be able to grant a user(someday a group) read only database permissions with the ability to view but not run or modify stored procedures across over a dozen databases. Is there a way to do this with the current database roles included with SQL Server 2005 or does the user have to be granted permissions on each individual stored procedure. Thank you.
GRANT VIEW ANY DEFINITION TO [Domain\UserName] worked for me.
At the bottom of most of our stored procedures we have a grant similar to
GRANT EXECUTE ON [dbo].[uspFOO] TO [DOMAIN\SQLServerUsers]
Luckily for me, our domain is changing and we now need to go through and change the permissions. Does anyone know of an easy way to do this using the DB metadata so I can pull out all the places where [DOMAIN\SQLServerUsers] is given permission to run and substitute it with [DOMAIN2\SQLServerUsers]?
Thanks.
For those asking, this is on SQL Server 2005.
What version of SQL Server are you on??
In 2005 and up, you could
create a new database role "db_executor" and do
GRANT EXECUTE TO db_executor
grant that database role to all necessary users
This will create a "catch all" role that has execute rights on every existing and future (!!) stored proc in your database. Yes, that does include future stored procs, too! Very handy indeed (at least as long as every user is allowed to execute all stored procs)
That way, you don't have to create separate GRANT EXECUTE statements for each and every stored proc.......
Can anyone help me with this problem please?
I have 2 databases on the same server, both owned by sa. A Windows login has permission to execute a stored proc in database A that selects data from a table database B. The stored proc and table are also both owned by dbo. The Windows login is a member of a Windows domain group that is a member of a database role in database A that has the permission to execute the stored proc, but it has not been granted or denied any permissions on database B directly. The login is able to execute stored procs in database A that use database A and other procs that access other databases that the login has permissions to already but when it attempts to execute this stored proc it generates the error "The server principal "" is not able to access the database "B" under the current security context." Cross database ownership chaining is enabled at the server level but the two databases have is_db_chaining_on = 0 in sys.databases.
Is it as simple as you have to enable cross-database ownership chaining at both the server and database level?
From memory if you enable cross-database chaining at the server level it is available for all databases, you do not have to specifically set it on the database level.
How did you set chaining on? For some system settings a restart is required, or you can run the RECONFIGURE command in a query window.
http://msdn.microsoft.com/en-us/library/ms176069(SQL.90).aspx