views:

150

answers:

2

I am using LinqToSQL and a trusted connection to handle database selects/updates/inserts/deletes. In the past I have always used stored procedures and only granted execute permission to the Application Pool identity for the particular sproc in the database. This is my first LinqToSql project (and I really love how much it helps). I would prefer not to grant dbo access to the application pool identity to get LinqToSql to work (but if that is recommended then I don't mind). What type of permissions can I grant to the Application Pool identity so that LinqToSql will have the minimum permissions? Or should I just go with dbo permissions and be done with it?

As per KristoferA's answer this is the permissions I granted the application pool identity in the database:
EXEC sp_addrolemember 'db_datareader', 'app_pool_identity'
EXEC sp_addrolemember 'db_datawriter', 'app_pool_identity'

Not exactly the same level of security as only granting execute permissions to the necessary sprocs but I am very good with it considering the huge development gains I have achieved just by using Linq2SQL. And it is better than granting the full dbo access.

+1  A: 

db_datareader and db_datawriter is enough if you just want to read and write data without messing around with schema changes and stuff...

KristoferA - Huagati.com
A: 

LinqToSQL creates dynamically generated SQL. As such, it needs full access to the data manipulation language commands (insert, update, delete). Your application account should not need access to data definition language commands (create, drop, alter, etc.).

Ryan Michela