I’ve always wondered why the list of database roles (db_datareader, db_datawriter, db_ddladmin, etc) never included a db_storedprocedureexecutor. The others make sense, but it seems like being able to grant the ability to execute all stored procs to a particular user (without granting them db_owner, which is the only other way to accomplish the same thing) would be a handy thing.
For example, say I want to give all of my developers the rights to run stored procedures, while not let them execute any DDL – without explicitly granting EXECUTE on every stored procedure (and then remembering to add the new ones when additional SPs are deployed), there’s not way to do this (I know that SPs can contain DDL, so they may still be indirectly allowed access to DDL this way).
If I have an application service account and a number of stored procedures that go along with my application, I have to grant rights explicitly to every SP (since I don’t want to grant my application service account DBO), whereas I can use a role to allow them to update/delete anything they want.
While it initially seemed obvious, I’m now not sure why this role is missing from the database server – can anybody offer an explanation of why this is a terrible idea (as I assume it is, or it would already exist)?
EDIT:
Seems I’m not the only one with this expectation – and it’s worked around with a handful of T-SQL (it seems you can grant a blanket EXECUTE right, which I wasn’t aware you could do), which just leaves me wondering why it’s not standard!
If you use schemas, then you only have to
GRANT EXECUTE ON SCHEMA::storedprocschemaeg
CREATE PROC storedprocschema.DoStuff ...As to why, no idea…