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 the SELECT privilege on all the base objects (for example tables and views) in the view.
To access a view, the view owner must have been granted the appropriate privilege on the underlying tables or views (with administration rights) and the user must have been granted the appropriate privilege on the view.
Updating with a WHERE clause requires both the SELECT and UPDATE privileges.
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 privileges 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 privileges on the objects that the procedure references.
Even if a user owns all the tables referenced by a procedure, the user cannot execute the procedure to access the tables unless the user has been granted the EXECUTE privilege 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
Discuter à propos de cette page dans DocCommentXchange.
|Copyright © 2013, SAP AG ou société affiliée SAP - SAP Sybase SQL Anywhere 16.0|