next up previous contents
Next: Checking update statement Up: Checking of the access Previous: Checking of the access   Contents

Checking insert statement

  1. Getting the action name, table name and the column names from the SQL statement which user want to execute. This information is taken from the record object.

  2. Verifying user access rights for the action and the table.
    Special ''SELECT'' statement is executed on the user access rights view. The action name and the table name (received in step 1) are used as a arguments in the WHERE clause. It returns allowed column names and descriptors for defined table and action.
    If there is some result from the SELECT statement then the access rights are valid for the action and the table and we can go to step 3. If there is no result (no record returned) user is not allowed to execute his SQL query and the algorithm is stopped.

  3. Verifying user access rights for the columns.
    Set of column from user SQL is matched with the sets of columns which are defined in the policies. If the algorithm finds the definition which is identical (or if the policy definition contain all column from user SQL) then the descriptor of this policy is collected (the order of column can be different but the names have to be the same). Algorithm goes through the all records returned in step 2 and accumulates all descriptors. Error message (no access rights) is generated in case if there is no applicable column definitions in the user rights.

  4. Verifying user access rights for the record .
    Now we have to prove all descriptors returned in the previous step. The value of each descriptor is set together with the value of the corresponding column from the user SQL1.7. If the value from user SQL is in the right with the descriptor value then the next pair of value is checked. If there is no compatibility for some pair of value then the error message is printed and action is stopped. The process of access rights checking is finished successfully if data introduced by the insert are contained in the user limitations.
Examples:
(1) INSERT INTO breeds(breed_id,country_id,lean_meat_avg)
      VALUE (50000055,500000001,68);
(2) INSERT INTO breeds(breed_id,country_id,lean_meat_avg)
      VALUE (50000055,500000001,45);
(3) INSERT INTO breeds(breed_id,tax_id)
      VALUE (50000055,6);
(4) INSERT INTO breeds(breed_id,country_id,tax_id,lean_meat_avg)
      VALUE (50000055,500000001,7,45);
(5) INSERT INTO breeds(breed_id,lang_id,intname)
      VALUE (50000055,300000001,'name');
If we look at our view (Table 1.10) then: - the first insert can be executed by the user because the lean_meat_avg is 68 and allowed range is 60-74
- the second insert can not be executed because lean_meat_avg is out of defined range
- the third insert can be executed
- the forth insert can not be executed because there is no such set of column definitions in any policy.
- the fifth insert can be executed if the owner name which will be inserted to the record is defined as PL (the owner is a special case which is existing only in EFABIS project and it is taken from the user table).


next up previous contents
Next: Checking update statement Up: Checking of the access Previous: Checking of the access   Contents
Marek Imialek 2006-06-22