|
| 1 | +--- |
| 2 | +title: "Ownership and user-schema separation in SQL Server" |
| 3 | +description: Learn how user-schema separation allows flexibility in managing SQL Server database object permissions. Schemas group objects into separate namespaces. |
| 4 | +ms.date: "08/02/2021" |
| 5 | +ms.prod: sql |
| 6 | +ms.technology: security |
| 7 | +ms.topic: conceptual |
| 8 | +ms.reviewer: vanto |
| 9 | +author: AndreasWolter |
| 10 | +ms.author: anwolter |
| 11 | +--- |
| 12 | +# Ownership and user-schema separation in SQL Server |
| 13 | + |
| 14 | +A core concept of SQL Server security is that owners of objects have irrevocable permissions to administer them. You can't remove privileges from an object owner, and you can't drop users from a database if they own objects in it. |
| 15 | + |
| 16 | +## User-schema separation |
| 17 | + |
| 18 | + User-schema separation allows for more flexibility in managing database object permissions. A *schema* is a named container for database objects, which allows you to group objects into separate namespaces. For example, the AdventureWorks sample database contains schemas for Production, Sales, and HumanResources. |
| 19 | + |
| 20 | + The four-part naming syntax for referring to objects specifies the schema name. |
| 21 | + |
| 22 | +```sql |
| 23 | +Server.Database.DatabaseSchema.DatabaseObject |
| 24 | +``` |
| 25 | + |
| 26 | +### Schema owners and permissions |
| 27 | + |
| 28 | + Schemas can be owned by any database [principal](../authentication-access/principals-database-engine.md), and a single principal can own multiple schemas. You can apply security rules to a schema, which are inherited by all objects in the schema. Once you set up access permissions for a schema, those permissions are automatically applied as new objects are added to the schema. Users can be assigned a default schema, and multiple database users can share the same schema. |
| 29 | + |
| 30 | + By default, when developers create objects in a schema, the objects are owned by the security principal that owns the schema, not the developer. Object ownership can be transferred with [ALTER AUTHORIZATION Transact-SQL](../../../t-sql/statements/alter-authorization-transact-sql.md) statement. A schema can also contain objects that are owned by different users and have more granular permissions than those assigned to the schema, although this isn't recommended because it adds complexity to managing permissions. Objects can be moved between schemas, and schema ownership can be transferred between principals. Database users can be dropped without affecting schemas. |
| 31 | + |
| 32 | +### Built-in schemas for backward compatibility |
| 33 | + |
| 34 | + SQL Server ships with nine pre-defined schemas that have the same names as the built-in database users and roles: *db_accessadmin, db_backupoperator, db_datareader, db_datawriter, db_ddladmin, db_denydatareader, db_denydatawriter, db_owner, db_securityadmin*. These exist for backward compatibility. The recommendation is to not use them for user objects. You can drop the schemas that have the same names as the fixed database roles - unless they're already in use, in which case the drop-command will simply return an error and block the drop of the used schema. |
| 35 | + |
| 36 | +```sql |
| 37 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_accessadmin') |
| 38 | +DROP SCHEMA [db_accessadmin] |
| 39 | +GO |
| 40 | + |
| 41 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_backupoperator') |
| 42 | +DROP SCHEMA [db_backupoperator] |
| 43 | +GO |
| 44 | + |
| 45 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_datareader') |
| 46 | +DROP SCHEMA [db_datareader] |
| 47 | +GO |
| 48 | + |
| 49 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_datawriter') |
| 50 | +DROP SCHEMA [db_datawriter] |
| 51 | +GO |
| 52 | + |
| 53 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_ddladmin') |
| 54 | +DROP SCHEMA [db_ddladmin] |
| 55 | +GO |
| 56 | + |
| 57 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_denydatareader') |
| 58 | +DROP SCHEMA [db_denydatareader] |
| 59 | +GO |
| 60 | + |
| 61 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_denydatawriter') |
| 62 | +DROP SCHEMA [db_denydatawriter] |
| 63 | +GO |
| 64 | + |
| 65 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_owner') |
| 66 | +DROP SCHEMA [db_owner] |
| 67 | +GO |
| 68 | + |
| 69 | +IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_securityadmin') |
| 70 | +DROP SCHEMA [db_securityadmin] |
| 71 | +GO |
| 72 | +``` |
| 73 | + |
| 74 | +If you drop these schemas from the model database, they won't appear in new databases. Schemas that contain objects cannot be dropped. |
| 75 | + |
| 76 | +The following schemas cannot be dropped: |
| 77 | + |
| 78 | +- `dbo` |
| 79 | +- `guest` |
| 80 | +- `sys` |
| 81 | +- `INFORMATION_SCHEMA` |
| 82 | + |
| 83 | +> [!NOTE] |
| 84 | +> The `sys` and `INFORMATION_SCHEMA` schemas are reserved for system objects. You cannot create objects in these schemas and you cannot drop them. |
| 85 | + |
| 86 | +#### The dbo schema |
| 87 | + |
| 88 | + The `dbo` schema is the default schema of every database. By default, users created with the CREATE USER Transact-SQL command have `dbo` as their default schema. The `dbo` schema is owned by the `dbo` user account. |
| 89 | + |
| 90 | + Users who are assigned the `dbo` as default schema don't inherit the permissions of the `dbo` user account. No permissions are inherited from a schema by users; schema permissions are inherited by the database objects contained in the schema. The default schema for a user is solely used for object-reference in case the user omits the schema when querying objects. |
| 91 | + |
| 92 | +> [!NOTE] |
| 93 | +> When database objects are referenced by using a one-part name, SQL Server first looks in the user's default schema. If the object is not found there, SQL Server looks next in the `dbo` schema. If the object is not in the `dbo` schema, an error is returned. |
| 94 | + |
| 95 | +## External resources |
| 96 | + |
| 97 | + For more information on object ownership and schemas, see the following resources. |
| 98 | + |
| 99 | +|Resource|Description| |
| 100 | +|--------------|-----------------| |
| 101 | +|[User-Schema Separation](/previous-versions/sql/sql-server-2008-r2/ms190387(v=sql.105))|Describes the changes introduced by user-schema separation. Includes new behavior, its impact on ownership, catalog views, and permissions.| |
| 102 | + |
| 103 | +## See also |
| 104 | + |
| 105 | +- [Protecting Your SQL Server Intellectual Property](../protecting-your-sql-server-intellectual-property.md) |
| 106 | +- [Getting Started with Database Engine Permissions](../authentication-access/getting-started-with-database-engine-permissions.md) |
| 107 | +- [Server-Level Roles](../authentication-access/server-level-roles.md) |
| 108 | +- [Securing ADO.NET Applications](/dotnet/framework/data/adonet/securing-ado-net-applications) |
0 commit comments