What are the ramifications of granting a DB User w

Question

If I have a user that only has limited permissions - just db_datareader and db_datawriter, which should only permit the user to query data and insert/edit/delete data, without allowing the user to add/modify/delete tables in the database.

There may be a need for the user to be able to execute stored procedures. If the user is given execute permissions (via the following sql: "GRANT EXECUTE TO UserName"), will the previous limitations (datareader and datawriter) still be enforced on what the user tries to execute through stored procedures? Or do Execute privileges really open up a pandora's box of other security holes (and if so, what)?

Answer 1

Granting execute permissions will allow that person to do anything which that stored procedure does in the context of that stored procedure (so if the sproc drops a table, the user will be able to execute the sproc to drop the table).

Edit, I just checked and I was wrong. Deny access does not revoke the ability to execute an action in a stored procedure.

Here is the article on MSDN which specifies that denying access does not affect a stored procedure.

http://msdn.microsoft.com/en-us/library/bb669058.aspx

UPDATE: What you might be able to do is execute a drop table command through sp_executeSQL in the stored procedure and deny the user the ability drop tables. That should prevent the stored procedure from being able to successfully execute the command (unless the user has the permissions to do so), since to use sp_executesql the user needs the permissions to perform the sql action and not just access to the stored procedure.

Answer 2

The concept you want is "ownership chaining"

Basically, permissions are not checked on objects in the same schema (say dbo) used by stored procedures. Except: deny is always checked.

So if stored proc dbo.uspDoStuff uses table dbo.Parent and dbo.Child, no permissions are needed on the tables and it just works. Unless you have run "DENY SELECT ON dbo.Parent to MyUser".

Note: You'd normally do "CREATE ROLE MyRole", add the user to the role, and grant permissions on the role. db_datareader is just a special, reserved role for example.

Answer 3

Execute permissions do not open up any extra security holes. In my opinion a larger hole is the fact that users have direct read/write access to the tables.

Since SQL Server implements ownership chaining you can provide controllable, auditable access to data by revoking datareader/datawriter permissions and providing all data access through stored procedures where users only have execute permissions. This will ensure that someone cannot arbitrarily insert/update/delete from tables. It will also provide another layer in a defense in depth strategy as in the event that an application that uses the database is vulnerable to a SQL Injection attack the attacker cannot read from/write to any table they want to.

The only caveat with doing this is if you are using an ORM it may take some additional development effort to use sprocs rather than letting the ORM dynamically generate the SQL.

Answer 4

If the owner of the stored procedure has the rights to select, insert, update or delete against a table then select, insert, update and delete statements inside the stored procedure will execute as long as the caller has execute rights on the stored procedure, even if the caller does not have rights to directly perform select, insert, update or delete against the table.

However a stored procedure can not perform DDL unless the caller has rights to perform DDL even if the owner of the stored procedure has DDL rights. Note this also applies to truncate table.

Answer: In your case granting db_datareader and db_datawriter to a user already gives the user full DML on all tables. Granting execute on any stored procedure will not give any additional rights.

Stored procedures can be used to increase data integrity by providing a gate through which all external programs must go. Do not grant insert, delete or update, but create SPs that do the work and enforce the appropriate rules about the data. (Above and beyond what can be done with constraints.) And as Joe Kuemerle points out, stored procedures can be used to increase security.

I have observed this behavior while developing an application on SQL Server 2000 and this even re-tested on SQL Server 2008 and found the same behavior. I have not been able to find documentation on this behavior.

Logged in as DBO and SA create a table:

create table dbo.SO (PK int identity constraint SO_PK primary key
    , SomeData varchar(1000)
)

Then create some stored procedures for basic DML:

create procedure dbo.InsertSO (@SomeData varchar(1000)) as
    begin
    insert into dbo.SO (SomeData) values (@SomeData)
    return SCOPE_IDENTITY()
    end
go

create procedure dbo.SelectSO (@PK int=null) as
    begin
    if @PK is not null
        select PK, SomeData from dbo.SO where PK = @PK
    else
        select PK, SomeData from dbo.SO
    end
go

create procedure dbo.CountSO as
    begin
    select COUNT(*) as CountSO from SO
    end
go

create procedure dbo.DeleteSO (@PK int=null ) as
    begin
    if @PK is not null
        delete dbo.SO where PK = @PK
    else
        delete dbo.SO
    end
go

create procedure dbo.UpdateSO (@PK int, @NewSomeData varchar(1000)) as
    begin`
    update dbo.SO
    set SomeData =  @NewSomeData
    where PK = @PK
    end
go

create procedure dbo.TruncateSO as
    begin
    truncate table dbo.SO
    end
go

As dbo, we can run the following SQL statements:

declare @PK_to_update int
insert into dbo.SO (SomeData) values ('Hello world!')
set @PK_to_update = SCOPE_IDENTITY()

declare @PK_to_delete int
insert into dbo.SO (SomeData) values ('Goodbye cruel world!')
set @PK_to_delete = SCOPE_IDENTITY()

insert into dbo.SO (SomeData) values ('Four score and seven years ago...')

select PK, SomeData
from dbo.SO

delete dbo.so
where PK = @PK_to_delete

update dbo.SO
set SomeData = 'Hello Milky Way!'
where PK = @PK_to_update

select PK, SomeData
from dbo.SO

truncate table dbo.SO

select COUNT(*) as CountSO from dbo.SO

Or do the equivalent via the stored procedures

go
declare @PK_to_update int
exec @PK_to_update = dbo.InsertSO 'Hello world!'

declare @PK_to_delete int
exec @PK_to_delete = dbo.InsertSO 'Goodbye cruel world!'

exec dbo.InsertSO 'Four score and seven years ago...'

exec dbo.SelectSO 

exec dbo.DeleteSO @PK_to_delete

exec dbo.UpdateSO @PK_to_update, 'Hello Milky Way!'

exec dbo.SelectSO

exec dbo.TruncateSO

exec dbo.CountSO

Now, create a DDL stored procedure and test:

create procedure dbo.DropSO as
    begin 
    drop table dbo.SO
    end
go
begin transaction
select TABLE_NAME from INFORMATION_SCHEMA.TABLES
where TABLE_NAME = 'SO'
exec dbo.DropSO
select TABLE_NAME from INFORMATION_SCHEMA.TABLES
where TABLE_NAME = 'SO'
rollback transaction

And now create another user and grant execute rights to all the stored procedure. Do not grant any other rights. (Assumes public does not have extra rights and mixed mode authentication. Mixed mode authentication is not recommended, but makes testing how rights are handled easier.)

exec sp_addlogin @loginame =  'SoLogin' , @passwd = 'notsecure', @defdb = 'Scratch'

exec sp_adduser @loginame = 'SoLogin', @name_in_db = 'SoUser'
go
grant execute on dbo.InsertSo to SoUser 
grant execute on dbo.InsertSO to SoUser
grant execute on dbo.SelectSO to SoUser
grant execute on dbo.CountSO to SoUser
grant execute on dbo.DeleteSO to SoUser
grant execute on dbo.UpdateSO to SoUser
grant execute on dbo.TruncateSO to SoUser
grant execute on dbo.DropSO to SoUser

Login in as SoLogin. Try the DML:

declare @PK_to_update int
insert into dbo.SO (SomeData) values ('Hello world!')
set @PK_to_update = SCOPE_IDENTITY()

declare @PK_to_delete int
insert into dbo.SO (SomeData) values ('Goodbye cruel world!')
set @PK_to_delete = SCOPE_IDENTITY()

insert into dbo.SO (SomeData) values ('Four score and seven years ago...')

select PK, SomeData
from dbo.SO

delete dbo.so
where PK = @PK_to_delete

update dbo.SO
set SomeData = 'Hello Milky Way!'
where PK = @PK_to_update

select PK, SomeData
from dbo.SO

truncate table dbo.SO
go
select COUNT(*) as CountSO from dbo.SO
go

drop table dbo.so

Nothing but errors:

Msg 229, Level 14, State 5, Line 2
The INSERT permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 229, Level 14, State 5, Line 6
The INSERT permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 229, Level 14, State 5, Line 9
The INSERT permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 229, Level 14, State 5, Line 11
The SELECT permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 229, Level 14, State 5, Line 14
The SELECT permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 229, Level 14, State 5, Line 14
The DELETE permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 229, Level 14, State 5, Line 17
The SELECT permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 229, Level 14, State 5, Line 17
The UPDATE permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 229, Level 14, State 5, Line 21
The SELECT permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 1088, Level 16, State 7, Line 24
Cannot find the object "SO" because it does not exist or you do not have permissions.
Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object 'SO', database 'Scratch', schema 'dbo'.
Msg 3701, Level 14, State 20, Line 2
Cannot drop the table 'SO', because it does not exist or you do not have permission.

Try the basic DML stored procedures:

declare @PK_to_update int
exec @PK_to_update = dbo.InsertSO 'Hello world!'

declare @PK_to_delete int
exec @PK_to_delete = dbo.InsertSO 'Goodbye cruel world!'

exec dbo.InsertSO 'Four score and seven years ago...'

exec dbo.SelectSO 

exec dbo.DeleteSO @PK_to_delete

exec dbo.UpdateSO @PK_to_update, 'Hello Milky Way!'

exec dbo.SelectSO

They work, because the owner of the SPs have the right rights, even though SoUser does not.

Try the truncate or drop stored procedure:

exec dbo.TruncateSO
go
exec dbo.DropSO

Errors again:

Msg 1088, Level 16, State 7, Procedure TruncateSO, Line 4
Cannot find the object "SO" because it does not exist or you do not have permissions.
Msg 3701, Level 14, State 20, Procedure DropSO, Line 4
Cannot drop the table 'SO', because it does not exist or you do not have permission.