Sybase 12.4.2 manual Using procedures for tailored security, 371

CHAPTER 10 Managing User IDs and Permissions

Example 2

Other permissions on views

TO SalesManager

Exactly the same command is used to grant permission on a view as to grant permission on a table.

The next example creates a view which allows the Sales Manager to look at a summary of sales orders. This view requires information from more than one table for its definition:

1 Create the view.

CREATE VIEW order_summary AS

SELECT order_date, region, sales_rep, company_name FROM "DBA".sales_order

KEY JOIN "DBA".customer

2 Grant permission for the Sales Manager to examine this view.

GRANT SELECT

ON order_summary

TO SalesManager

3To check that the process has worked properly, connect to the SalesManager user ID and look at the views you have created:

CONNECT SalesManager IDENTIFIED BY sales ;

SELECT * FROM "DBA".emp_sales ;

SELECT * FROM "DBA".order_summary ;

No permissions have been granted to the Sales Manager to look at the underlying tables. The following commands produce permission errors.

SELECT * FROM "DBA".employee ;

SELECT * FROM "DBA".sales_order;

The previous example shows how to use views to tailor SELECT permissions. INSERT, DELETE, and UPDATE permissions can be granted on views in the same way.

For information on allowing data modification on views, see “Using views” on page 129.

Using procedures for tailored security

While views restrict access on the basis of data, procedures restrict the actions a user may take. As described in “Granting permissions on procedures” a user may have EXECUTE permission on a procedure without having any permissions on the table or tables on which the procedure acts.

371