SQL Server : permissions to allow disable/reenable FK constraint, but no other alter - sql

Question

Are there permission settings that will allow a principal to disable/enable a foreign key constraint, but not allow other table alteration?
E.g.: from a 'dbo' principal:
create login ref_test with password = 'test1234'
create user ref_test
exec sp_addrolemember 'db_datareader', 'ref_test'
exec sp_addrolemember 'db_datawriter', 'ref_test'
create table A (ID int not null, constraint PK_A primary key (ID))
create table B (Aid int not null, constraint FK_Aid_AID foreign key (Aid) references A(ID))
From a ref_test login-connection:
insert A values (1)
insert B values (1)
Now, I need to be able to update the key in the FK relationship, like so:
-- will fail
ALTER TABLE B NOCHECK CONSTRAINT FK_Aid_AID
update A set ID = ID + 1
update B set AID = AID + 1
ALTER TABLE B WITH CHECK CHECK CONSTRAINT FK_Aid_AID
This fails with
Msg 1088, Level 16, State 13, Line ...
Cannot find the object "B" because it does not exist or you do not have permissions
If I add
GRANT ALTER on B to ref_test
It will work, but not without also enabling ALTER TABLE B DROP CONSTRAINT FK_Aid_AID, as well as enabling other DDL on the table--add/drop columns, other constraints--though not allowing the FK in question to be re-added--that requires an additional GRANT REFERENCES (ID) on A to ref_test.

Answer 1

No, there's no way to do this with SQL Server's permission scheme. To perform any particular ALTER TABLE statement you need ALTER permission, and that in turn allows you to perform any ALTER TABLE statement whatsoever, save those that require updating columns or referencing external types or columns (which require separate rights).
One general way of granting accounts permission to do things they wouldn't otherwise be able to do (and only those things) is to encapsulate them in stored procedures that execute under privileged accounts. So let's say you want to give an account the ability to disable or enable any constraint on any table, but not to do anything else DDL-related with those tables:
CREATE PROCEDURE nocheck_constraint(#table SYSNAME, #constraint SYSNAME)
WITH EXECUTE AS OWNER AS
BEGIN
SET NOCOUNT ON;
DECLARE #SQL NVARCHAR(MAX);
SET #SQL = REPLACE(REPLACE(
'ALTER TABLE $table NOCHECK CONSTRAINT $constraint;',
'$table', QUOTENAME(#table)),
'$constraint', QUOTENAME(#constraint))
;
PRINT #SQL;
EXEC(#SQL);
END;
GO
-- The following is necessary only for direct calls.
-- Note that ownership chaining will allow *any* stored procedure to call this one without
-- a separate permission check, which is a double-edged sword.
GRANT EXECUTE ON nocheck_constraint TO [unprivileged_account];
And similarly for check_constraint. Of course you can make this more fine-grained as you require.
I'm taking a potentially dangerous shortcut here by leveraging EXECUTE AS OWNER so I can do dynamic SQL without security restrictions. If you are not in full control of the database and all procedures created in it, this has some consequences for the security of not just the database, but the rest of the server as well. In that case, you may want to look into signing the procedure and using a proxy instead. Instead of hashing that all out here, I refer you to Erland Sommarskog's excellent writeup on the matter.

Answer 2

I have user(s) for which I wont to give permission in Management Studio to change extended properties for columns of table(s).
So when give ALTER permission on table for that user it can be seen Keys, Indexes, Constraint, even it can not be changed. So not to be seen there is DENY on SELECT in sys.check_constraint, sys.foreignkeys, sys.key_constraint ....
So maybe with ALTER ON tables and some combination of DENY and GRANT on sys.columns, sys.foreignkeys, sys.check_constraint....it is possible to allow a principal to disable/enable a foreign key constraint, but not allow other table alteration

Answer 3

Msg 1088, Level 16, State 13, Line ...
Cannot find the object "B" because it does not exist or you do not have permissions
if I do this with management studio, I notice next:
if I don't have SELECT permission on particular table it will be a problem, all ForeignKey will be disappear
If I don't have SELECT permission then in CheckExistingData on Creation or Enabling if it is yes it should be changed in No, and EnforceForeignKey Constraint can be changed from Yes to No, or opposite
So :
1. or SELECT permission on table (which is needed for CheckExistingDataOnCreatinon or Reanabling if it is set to Yes)
2. or CheckExistingDataOnCreation or Reanablig (creating again) set to No