A Tale of Two Database Principals, part I: Introduction

Jeffrey Richardson — Sun, 26 Jul 2009 00:52:48 GMT

I have been working on a web application which requires a database backend for the model. The hosting provider I am using hosts SQL Server 2005 databases, so I decided to setup a database. To my delight, the hosting provider allows to set up an optional second “read only” set of credentials. Upon setting up the database, I decided to do a little research on what these database principals can do.

I’ve found that, by default, the full access principal is granted full control of the database, an extra schema is created with the same name as the read only principal which is then assigned to that principal, and, outside of its own schemas, the read only principal is only granted SELECT and REFERENCES to tables and views , with no access to any other object types.

On the surface, this allows using the full access principal to create tables and views, as well as populating the tables, which the read only principal can then read without worry for modifying the data. If read only data is too limited, the read only principal can create all object types, as well as insert/update/delete tables as well as execute procedures as long as they are part of a schema assigned to the read only principal. In this rather limited default setup, this allows one to protect certain data that should never be modified or deleted. In later articles, I’ll discuss more powerful setups which can be achieved based on this setup.

Model

A Tale of Two Database Principals, part I: Introduction