Table of Contents
Advertisement
Note
Using views and procedures for extra security
CHAPTER 10
SELECT *
FROM company.customers
To rectify the situation, make the
GRANT GROUP TO company;
GRANT MEMBERSHIP IN GROUP company TO Sales;
Now Joe and Sally, being members of the
of the
group, and can reference their tables without qualifiers. The
company
following command will now work:
SELECT *
FROM Customers
Joe and Sally do not have any extra permissions because of their membership
in the
group. The
company
table permissions. (The
company
tables like
because it created the tables and has DBA authority.) Thus,
Salaries
Joe and Sally still get an error executing either of these commands:
SELECT *
FROM Salaries;
SELECT *
FROM company.Salaries
In either case, Joe and Sally do not have permission to look at the
For databases that require a high level of security, defining permissions directly
on tables has limitations. Any permission granted to a user on a table applies to
the whole table. There are many cases when users' permissions need to be
shaped more precisely than on a table-by-table basis. For example:
•
It is not desirable to give access to personal or sensitive information stored
in an employee table to users who need access to other parts of the table.
•
You may wish to give sales representatives update permissions on a table
containing descriptions of their sales calls, but limit such permissions to
their own calls.
In these cases, you can use views and stored procedures to tailor permissions
to suit the needs of your organization. This section describes some of the uses
of views and procedures for permission management.
Managing User IDs and Permissions
group a member of the
Sales
group, are indirectly members
Sales
group has not been explicitly granted any
company
user ID has implicit permission to look at
group.
company
table.
Salaries
369
Advertisement
Table of Contents
