Stairway to SQL Server Security

Stairway to SQL Server Security Level 6: Execution Context and Code Signing

A fundamental way that SQL Server determines whether a principal has the permissions necessary to execute code is with its execution context rules. It’s all complicated by the possibility that a principal has permission to execute code but doesn’t have permission on the underlying objects accessed by the code, such as the data in a table. This stairway level will explore SQL Server’s execution context, ownership chains, and impersonation, as well as show you how you can control access to data via T-SQL code.

External Article

Centralize Your Database Monitoring Process

SQL Server Data Collector, together with Management Data Warehouse, is a fine and useful component for gathering information centrally about how SQL Server instances are being used, and thereby keeping an eye out for problems. It comes into its own when you have figured out how to configure it to run on maybe hundreds of instances using Central Management Server. Dennes describes how to tame the system so that it scales.

External Article

Managing the Big Data Technical Staff

Big data is everywhere, and most large IT enterprises have installed one or more big data applications. These applications provide fast access to large stores of data, usually customer or sales data. Your technical staff that supports these applications and the systems that analyze and consume the data didn't exist ten years ago. Who are these new IT professionals, and how should you manage them?

Technical Article

SQL Saturday #374 - Austria

SQL Saturday is holding its first event in Vienna on February 28, 2014. With over 20 sessions on SQL Server, the event is aimed at all those interested in SQL Server - from pros to beginners. Register while space is available.

SQLServerCentral Article

Expediency versus Best Practice!

Rumour has it that some grand old houses in the British Isles may be haunted. A SQL Server consultant spends a night in such a house musing over the use of T-SQL versus SSIS. The story is entirely fictitious and the article has been written pro bono and dedicated to the SQL Server community. For its interest, amusement and imagination.

Blogs

Prime Day Recommendations

By

It’s Prime Day. A few of my recommendations, since I want to do some...

Fabric for Operational Reporting & SQL Endpoint Trap

By

With Fabric Mirroring, Microsoft is promoting a nice and appealing story for operational reporting...

Crawl, Walk, Run with Agentic Development of Power BI Assets

By

If you’ve been watching AI roll through the data community and thinking, “this seems...

Read the latest Blogs

Forums

SQL Art, Part 4: Happy 4th of July — A British DBA's Guide to Celebrating a War We Don't Talk About

By Terry Jago

Comments posted to this topic are about the item SQL Art, Part 4: Happy...

Finding 'bad' characters

By Barcelona10

Hi All I am trying to find 'bad' characters that users might type in....

Extreme DAX: Take your Power BI and Fabric analytics skills to the next level

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Extreme DAX: Take your Power...

Visit the forum

Question of the Day

Changing the Schema

I set up a few users on my SQL Server 2022 instance.

CREATE LOGIN User1 WITH PASSWORD = 'Demo12#1'
CREATE USER User1 FOR LOGIN User1
GO
CREATE LOGIN User2 WITH PASSWORD = 'Demo12#2'
CREATE USER User2 FOR LOGIN User2
GO
CREATE LOGIN User3 WITH PASSWORD = 'Demo12#3'
CREATE USER User3 FOR LOGIN User3
GO
I then created a schema that one of them owned. Under this schema, I added a table with some data.
CREATE SCHEMA MySchema AUTHORIZATION User1
GO
CREATE TABLE Myschema.MyTable(myid INT)
GO
INSERT MySchema.MyTable
(
    myid
)
VALUES
(1), (2), (3)
GO
SELECT * FROM MySchema.MyTable
GO
I granted rights and verified that User2 could access this table.
GRANT SELECT ON Myschema.MyTable TO User2
GO
SETUSER 'USER2'
GO
SELECT * FROM MySchema.MyTable
GO
This worked. Now, I move this schema to a new user.
ALTER AUTHORIZATION ON SCHEMA::Myschema TO User3;
GO
What happens with this code?
SETUSER 'USER2'
GO
SELECT * FROM MySchema.MyTable
GO

See possible answers