Predicated privilege enforcement may leak information about rows in a table to a user who is not authorized to see the data, or may violate data consistency.
For example, if employee IDs are sensitive and unique, and user Joe is entitled to process IDs only for those employees who work in the sales department, when Joe updates the ID of an employee in the sales department, Joe can get confirmation about whether a particular ID exists in the entire table by whether or not Adaptive Server issues a uniqueness-violation message.
Updateable views have the same potential for leaked information. Application designers who rely on access control through predicated privileges should disallow updates of primary keys, and should restrict the users with predicated update and delete privileges on tables with referential constraints.
In the following example, the column cust_name is a foreign key on the table t_orders that is constrained by the values of customer.name:
create table t_orders (ordernum int, orders_dt date, cust_name char(60) references customer.name, state char(2))
An employee in the orders department has select and update permission on the t_orders table for those orders shipped to customers in the state of Iowa.
grant select, update on t_orders where state = 'IO' to procure_role
The employee in the orders department may not have access to the customer table, which lists customers of the company nation-wide. The employee wants to know whether a certain customer from New York buys from this company. Using the customer name of the New York customer, the employee enters the following command to update an order placed in Iowa:
update orders set cust_name = 'Ronald Crump' where ordernum = 345
If above statement does not return a foreign key constraint violation, the employee knows that Ronald Crump is a customer of the company.
