Devildog74 wrote:
Is it a true statement that the SQL User account being used by the DQE must be a member of the db_owner role in order to run code that performs select, insert, update, and delete statements?
No.
1) the user specified in the connection string has to be a member of the 'public' role of the catalog
2) the user specified in the connection string has to have select rights on the tables it accesses, insert rights on the table it inserts data in etc. That's it.
I was under the impression that the when the DQE runs, it turns the object graph into a call to sp_executesql, and that this stored procedure required db_owner level access?
It calls ADO.NET statements. The SqlClient of .NET turns a command execution into a call to sp_executesql.
I was also under the impression that simply adding the sql user account in question to the db_datareader and db_datawriter role would not be sufficient.
The reason I am asking this is because I have a client who beleives that using LLBLGen will violate their threat model because of 1. sql injection, and 2. elevate permissions that are required.
sql injection is impossible, all values are parameterized. There's no value inserted into the query.
the user doesn't have to be owner of the db.
With regards to sql injection, I have tried to explain to them that the only way you could possibly be faced with sql injection would be when someone injected their own object into the DQE pipeline, and that if something like that should happen, then they have much worse problems to deal with.
So I am still battling with regards to the permissions issue.
What have you tried and what failed?
Be sure the user is part of the public role so it can actually access the db.
