Does SQL Server ownership chaining not work for ALTER? - sql-server

Question

I have a case where SQL Server ownership chaining doesn't seem to work - or am I missing something?
I have two schemas: Schema1 and Schema2.
In Schema1, I only have SELECT permissions, while in Schema2, I only have EXEC permissions.
I call a stored procedure in Schema2 which inserts a record into a table in Schema1.
This works fine (even though I don't have INSERT permissions in Schema1) due to ownership chaining.
Now, when I call another stored procedure which turns off the identity column in the table before inserting I get an error:
Msg 1088, Level 16, State 11, Procedure Schema2.AddRecordWithSpecificId, Line 7 [Batch Start Line 60]
Cannot find the object "Schema1.MyTable" because it does not exist or you do not have permissions.
If I grant ALTER permissions to Schema1, it works fine - but why is that necessary? Why doesn't schema chaining work in this case?
Script that reproduces the problem:
CREATE DATABASE OwnershipChainingTest
GO
USE OwnershipChainingTest
GO
CREATE SCHEMA Schema1 AUTHORIZATION [dbo]
GO
CREATE SCHEMA Schema2 AUTHORIZATION [dbo]
GO
CREATE TABLE Schema1.MyTable
(
Id int IDENTITY(1,1) NOT NULL,
Title varchar(50) NOT NULL
)
GO
CREATE PROCEDURE Schema2.AddRecord
#title nvarchar(100)
AS
BEGIN
INSERT INTO Schema1.MyTable (Title)
VALUES (#title)
END
GO
CREATE PROCEDURE Schema2.AddRecordWithSpecificId
#id int,
#title nvarchar(100)
AS
BEGIN
SET IDENTITY_INSERT Schema1.MyTable ON
INSERT INTO Schema1.MyTable (Id, Title)
VALUES (#id, #title)
SET IDENTITY_INSERT Schema1.MyTable OFF
END
GO
CREATE USER MyUser WITHOUT LOGIN
GO
CREATE ROLE MyRole AUTHORIZATION [dbo]
GO
EXEC sp_addrolemember MyRole, MyUser
GO
-- With this it works: GRANT SELECT, ALTER ON Schema::Schema1 TO MyRole
GRANT SELECT ON Schema::Schema1 TO MyRole
GO
GRANT EXEC ON Schema::Schema2 TO MyRole
GO
EXEC AS user = 'MyUser'
EXEC Schema2.AddRecord 'hello1'
GO
-- This causes an error
EXEC Schema2.AddRecordWithSpecificId 42, 'hello2'
GO
REVERT;
--SELECT CURRENT_USER
SELECT * FROM Schema1.MyTable
USE MASTER
DROP DATABASE OwnershipChainingTest
GO

Answer 1

Ownership chaining applies only to DML. SET IDENTITY_INSERT is essentially a DDL operation, which is why it requires at least ALTER permissions on the table.
A good way to allow minimally privileged users with only execute permissions to run the proc is by signing the proc with a certificate based on a user with ALTER permissions:
--create certificate and sign proc
CREATE CERTIFICATE AddRecordWithSpecificIdCert
ENCRYPTION BY PASSWORD = 'temporary password'
WITH SUBJECT = 'Allow ALTER on Schema1';
ADD SIGNATURE TO Schema2.AddRecordWithSpecificId BY CERTIFICATE AddRecordWithSpecificIdCert WITH PASSWORD = 'temporary password';
--remove ephemeral private key
ALTER CERTIFICATE AddRecordWithSpecificIdCert REMOVE PRIVATE KEY;
--create a user from certificate with the needed permissions
CREATE USER AddRecordWithSpecificIdCertUser FROM CERTIFICATE AddRecordWithSpecificIdCert;
GRANT ALTER ON SCHEMA::Schema1 TO AddRecordWithSpecificIdCertUser;
GO
--this test now works
EXEC AS user = 'MyUser';
GO
EXEC Schema2.AddRecordWithSpecificId 42, 'hello2'
GO
REVERT;
GO