Changing ownership on nested objects

Views and procedures can access underlying objects that are owned by different users. For example, if usera, userb, userc, and userd were four different users, userd.viewd could be based on userc.viewc, which could be based on userb.viewb, which could be based on usera.tablea. Similarly for procedures, userd.procd could call userc.procc, which could call userb.procb, which could insert into usera.tablea.

The following Discretionary Access Control (DAC) rules apply to nested views and tables:

To create a view, the user must have SELECT permission on all of the base objects (for example tables and views) in the view.
To access a view, the view owner must have been granted the appropriate permission on the underlying tables or views with the GRANT OPTION and the user must have been granted the appropriate permission on the view.
Updating with a WHERE clause requires both SELECT and UPDATE permission.
If a user owns the tables in a view definition, the user can access the tables through a view, even if the user is not the owner of the view and has not been granted access on the view.

The following DAC rules apply to nested procedures:

A user does not require any permissions on the underlying objects (for example tables, views or procedures) to create a procedure.
For a procedure to execute, the owner of the procedure needs the appropriate permissions on the objects that the procedure references.
Even if a user owns all the tables referenced by a procedure, the user will not be able to execute the procedure to access the tables unless the user has been granted EXECUTE permission on the procedure.

Following are some examples that describe this behavior.

Example 1: User1 creates table1, and user2 creates view2 on table1
Example 2: User2 creates procedure2 that accesses table1
Example 3: User1 creates table1, user2 creates table2, and user3 creates view3 joining table1 and table2

Send feedback about this page via email or DocCommentXchange