February 6, 2018 at 3:31 am
We have a number of T-SQL statements contained in a variable @sql nvarchar(MAX) which need to be executed within a stored procedure at runtime. For example:
CREATE mysproc AS
DECLARE @sql nvarchar(MAX);
SELECT @sql = 'DELETE FROM db1.dbo.Table1;'
SELECT @sql += 'DELETE FROM db2.dbo.Table1'
SELECT @sql += 'DELETE FROM db3.dbo.Table1'
EXEC (@SQL);
GO
However, we are receiving errors relating to security around this.
We suspect we may need to create a SQL login, which is mapped to all relevant databases within the instance, and then create individual users within each database which map to this login, before applying the db_datareader database role to each user.
We have done this, however this is returnning the following error message:
The server principal "S-1-9-3-1979612751-1205369817-371524777-3428266560." is not able to access the database "db1" under the current security context.
Is anyone please able to detail what we need to do to achieve this? We don't want to open up any vulnerabilities, but require the stored procedure to be able to delete data from tables across several databases as detailed above.
Many thanks
February 6, 2018 at 4:16 am
This was removed by the editor as SPAM
February 6, 2018 at 4:36 am
zoggling - Tuesday, February 6, 2018 3:31 AMWe have a number of T-SQL statements contained in a variable @sql nvarchar(MAX) which need to be executed within a stored procedure at runtime. For example:CREATE mysproc AS
DECLARE @sql nvarchar(MAX);
SELECT @sql = 'DELETE FROM db1.dbo.Table1;'
SELECT @sql += 'DELETE FROM db2.dbo.Table1'
SELECT @sql += 'DELETE FROM db3.dbo.Table1'
EXEC (@SQL);
GOHowever, we are receiving errors relating to security around this.
We suspect we may need to create a SQL login, which is mapped to all relevant databases within the instance, and then create individual users within each database which map to this login, before applying the db_datareader database role to each user.
We have done this, however this is returnning the following error message:
The server principal "S-1-9-3-1979612751-1205369817-371524777-3428266560." is not able to access the database "db1" under the current security context.
Is anyone please able to detail what we need to do to achieve this? We don't want to open up any vulnerabilities, but require the stored procedure to be able to delete data from tables across several databases as detailed above.
Many thanks
If you want to delete, you'll need more than db_datareader. But I don't think that's the cause of your error message. I take it the login you created isn't called S-1-9-3-1979612751-1205369817-371524777-3428266560? Do you get the same error in every database? What do you get if you run this query (it's from memory so the columns and syntax may not be 100% correct)?
SELECT * FROM sys.server_principals l
JOIN db1.sys.database_principals u ON l.sid = u.sid
WHERE l.name = 'MyLoginName'
John
February 6, 2018 at 5:54 am
Hi John,
Thank you for your reply, yes apologies you have spotted two typos of mine:
- The login is called something very simple (e.g. "DeleteMyRows") rather than the string of numbers and letters I posted. This was a hangover from a "SQL user without login" test we ran, but we suspect this will not work since the stored procedure needs to delete from (and authenticate with) multiple databases.
- I meant db_datawriter rather than db_datareader, apologies.
Do we need to grant explicit DELETE permissions on each of the tables the database User needs to delete from?
What steps do we essentially need to take to get a stored procedure to be able to delete from tables in multiple databases in the way I mentioned previously?
February 6, 2018 at 6:02 am
You didn't post the results of the query I posted, but I suspect the user doesn't exist in the target database, or is orphaned.
USE db1
CREATE USER DeleteMyRows FROM LOGIN DeleteMyRows
or
USE db1
ALTER USER DeleteMyRows WITH LOGIN = DeleteMyRows
I've never tried creating a stored procedure to do operations in more than one database at a time. Have a read about cross-database ownership chaining and see what works for you. Don't enable CDOC if you can avoid it - it's a security minefield!
John
February 9, 2018 at 2:37 am
Apologies for the delayed response. Not wanting to resort to CDOC, we found a workaround as follows:
- We split the stored procedure into two, the first with hard-coded delete statements against a different database (not requiring any additional security), the second with dynamic statements against the main database using EXEC(@SQL); Create both procedures on the main database.
- Create a user without login on the main database and add to the db_datareader and db_datawriter database roles.
- Run the second stored procedure in the context of this new user (i.e. EXECUTE AS 'MyUser').
This seems to have been the workaround for us, but I am sure CDOC could have been of help too so I will mark both as part of the answer, thank you for your help.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply