I have a stored procedure called testSP in my SQL Server Express database.
I am able to execute it using
exec [db_owner].[testSP]
but if I use exec testSP it doesn't work.
What is the cause of this?
I have other databases which do not exhibit this behavior.
Thanks for your help.
Your user is set up with dbo as it's default schema. That's pretty normal
when you run
exec testSP
it's using your default schema which is dbo, so it is running this:
exec [dbo].[testSP]
which doesn't exist.
When you run
exec [db_owner].[testSP]
it find and runs that stored procedure
I don't know the background but I guess someone has incorrectly/accidentally created and used a schema called db_owner
In all the db's that work, I guess the objects are in the dbo schema or your user is set up to use the correct schema. Go look in the object browser and compare
If you want to move the stored procedure into the dbo schema run this:
ALTER SCHEMA dbo TRANSFER [db_owner].[testSP];
If you want to change your users default schema to db_owner run this:
ALTER USER [youruser] WITH DEFAULT_SCHEMA = db_owner;
I reckon the db_owner schema is an accident though.
Related
I am getting the following error when trying to run a stored procedure:
The SELECT permission was denied on the object 'tblMarketContact_Type_link', database 'FMS', schema 'Marketing'.
The stored procedure was running fine before I included this table. It has execute permissions for the database role it is being ran under. It uses dynamic SQL.
I am guessing it has something to do with the stored procedure being in a separate schema from the table? The stored procedure is just in the dbo schema.
What is the best way to fix this? I would think simply granting select permissions on this table for the security role would be an easy fix, but I want to avoid that. I'd like for only the stored procedure to have permission to execute and select from that table.
You can use Grant statement on a role an use that role to execute a stored procedure like
Create Role xyz;
Grant execute on "your_stored_procedure_name" to newrole;
If you don't want to use a new role, then you can use grant statement for a particular schema.
Grant select on "your stored procedure name" to "user";
I'd like to give a non-admin the ability to create folders on the SQL server's local hard disk using xp_create_subdir. Reason - need to create a folder structure so that manufacturing equipment can FTP large files. Meta data for the files is stored in SQL.
Server is SQL 2016 Express. OS is Windows 10 Pro.
I've found lots of explanations of how to get this to work but can't figure out what I'm missing. Using the SA account I've created a stored procedure like this:
use [DBname]
CREATE PROCEDURE dbo.usp_CreateDirectory
#directoryFullPath varchar(500)
WITH EXECUTE AS owner
AS
BEGIN
SET NOCOUNT ON;
EXEC master.dbo.xp_create_subdir #directoryFullPath;
END
GO
GRANT EXECUTE ON dbo.usp_CreateDirectory TO [TestUser]
GO
Code to run the stored procedure:
DECLARE #RC int
DECLARE #directoryFullPath varchar(500)
set #directoryFullPath = 'd:\FTP_Root\2020\08\22\'
EXECUTE #RC = dbo.usp_CreateDirectory
#directoryFullPath
GO
In Windows I've given NT Service\MSSQL${InstanceName} full access to d:\FTP_Root\
What am I missing? Running xp_create_subdir 'C:\FTP_Root\2020\08\22' in MSSMS works fine.
Running the stored procedure as SA or the non-admin TestUser gives this result:
Msg 229, Level 14, State 5, Procedure xp_create_subdir, Line 1 [Batch
Start Line 2] The EXECUTE permission was denied on the object
'xp_create_subdir', database 'mssqlsystemresource', schema 'sys'.
I found this on another site: https://www.sqlservercentral.com/forums/topic/xp_create_subdir-for-non-sysadmins
The headlines here are two main points
Although this post is old,
In order to solve this issue, you should make sure that your database is Trustworthy - since the SP xp_create_subdir is on different DB
You still need to set "with Execute as 'dbo'
alter database [DBNAME] set trustworthy on
- Guy-456224
And DO understand the security ramifications of using SET TRUSTWORTHY ON. It may not be a problem or... it may. "It Depends" but you won't know until you read about it.
- Jeff Moden
I completely agree with Jeff on this one. If you remotely care about security, understand what the TRUSTWORTHY setting does before adjusting it.
I think the larger question here is to ask why SQL Server needs to create the directory? Powershell could both query the database for the Directory Path and create the Directory. You could have a SQL Server Agent job that will execute this under the security context of either a SQL Server Proxy account, or the SQL Agent service account (I would pick the proxy account personally, but that's just me).
I want to create three SQL Server database roles.
That can CREATE, ALTER and EXECUTE all stored procedures in database
That can only EXECUTE all stored procedures in database
That have no access to any stored procedures in database
I have created the roles, but I'm facing issues while REVOKE their permissions.
I have executed
REVOKE CREATE PROCEDURE TO [ROLE NAME]
to revoke the permissions to create the procedure and it executed successfully.
But I got error while executing this statement:
Error: Incorrect syntax near 'ALTER'.
I am very new to SQL server role rights so I might be completely wrong with my approach.
Please guide me to achieve my goal in correct way.
Thanks
From the documentation Create a Stored Procedure:
Permissions
Requires CREATE PROCEDURE permission in the database and ALTER
permission on the schema in which the procedure is being created.
Therefore just giving CREATE PROCEDURE on it's own won't allow you to create a procedure. In fact, giving a ROLE the CREATE PROCEDURE permission, and not ALTER on the schema will result in the below error:
The specified schema name "dbo" either does not exist or you do not have permission to use it.
There is no ALTER PROCEDURE permissions, therefore, for a member of a ROLE to be able to both CREATE and ALTER a PROCEDURE you would need to do:
GRANT CREATE PROCEDURE TO YourRole;
GRANT ALTER ON SCHEMA::dbo TO YourRole; --Replace with appropriate schema name
This, however, will also enable to user to ALTER anyprocedures on said schema. Ut also enable those in the role to ALTER other objects on the schema as well (such as tables) though.
If your ROLE has permissions to ALTER the procedures and you want to remove that, you would need to run the below:
REVOKE ALTER ON SCHEMA::dbo TO YourRole;
This will, as mentioned, also revoke their ability to ALTER any other objects on said schema.
Remember, REVOKE doesn't DENY, it simply means that the USER won't inherited that permission from that ROLE any more. If the USER has the permission from a different ROLE, or they have the permission themselves, they will be able to continue to use the permission. If you must stop a USER from performing an action, regardless of any other permissions, they must have the DENY permission.
1) That can CREATE, ALTER and EXECUTE all stored procedures in
database
That's the db_owner role, or the CONTROL permission on the database. Anyone with all those permissions can escalate their own privileges to a database-level admin. So don't try.
2) That can only EXECUTE all stored procedures in database
GRANT EXECUTE TO [SomeRole]
3) That have no access to any stored procedures in database
A user has no access to any stored procedure unless you grant permissisions or add them to a role that has permissions.
There is a user and two databases on server (db1 and db2).
User can connect to server having default database db1 where he can exec sp.
In sp syntax we use synonyms for db2 tables under dbo scheme.
All that is done in order to allow user just connect and exec one stored procedure. It worked noraml but now The server principal "user" is not able to access the database "db2" under the current security context.
User gets output from sp when code does not touch synonyms to db2.
What should be updated? I cant grant select to user for db2 objects.
I know the question is old, but still relevant
the procedure has to have permission on the synonym object
the procedure has to have permission on the object the synonym is targeting
you have to correctly setup trustworthy database property
By default, the procedure executes under the caller account, but it can be changed with execute as clause.
My requirement is that user performing alter CANNOT be sysadmin (it can have all other rights but not sysadmin).
I am running a query from local server which should modify a remote one
EXEC ('ALTER DATABASE REMOTEDB MODIFY FILEGROUP ftfg_REMOTEDB NAME=ftfg_REMOTEDB') at [REMOTESERVER]
This query works once I add sysadmin right to the user but without the right, it give the following error:
The server principal "USERWITHOUTSYSADMIN" is not able to access the database "REMOTEDB" under the current security context.
I am on SQL Serve 2008.
Please Help!
After much research: This is not possible:(
Put the EXEC command in a stored procedure and grant execute on the procedure to the user. It won't STOP a sysadmin from executing it, but it will allow others to execute it as well. Be VERY, VERY careful with this!
Can you allow the user to impersonate someone with the appropriate permissions?
EXEC ('ALTER DATABASE REMOTEDB MODIFY FILEGROUP ftfg_REMOTEDB NAME=ftfg_REMOTEDB')
AS USER = 'UserWithAppropriatePermissions'
AT [REMOTESERVER]