Prev  Up  Next
Chapter 23. How Veil2 Relates to the Original Veil  Home  Chapter 25. Performance

This section provides whatever tips and guidelines have occurred to the author. We can hope that the section expands over time.

Generally, with a well-behaved application and well-implemented database design, Veil2 adds little performance overhead. This is because it, mostly, only applies permission checks on the records that the user sees. If the user is only going to see a few records, the overhead of checking those few records is going to be small.

However, if you make Veil2 do your query filtering for you instead of writing properly crafted where-clauses, performance is going to suck. Consider the following queries:

select stuff
  from parties
 where org_id = 20
   and party_name like '%Bob%';

select stuff
 from parties
where party_name like '%Bob%';
      

Assume that we are in a Veil2-protected database and that we have select access only to org_id 4.

Both queries will return the same number of rows. But in a database with lots of parties, the second query will be slow.

In the second query, a full-table scan will be performed, and many Bobs from other orgs might be returned, only to be discarded by the Veil2-based security policy.

The first query will, most likely, use an index and return a much smaller set of records, which will then be filtered looking for Bob, and finally checked against the security policy. In this case the security policy has only had to check records that the user was allowed to see anyway.

For most applications, any time that a security policy blocks something, the application has done something wrong. You should consider this a bug in the application. Although no harm will be done, this is an indication of one of two things:

  • the application has not been properly implemented;

  • your security policy is over-restrictive.

In either case, it makes sense to note the occurrence and investigate. Note that in a reporting environment where ad-hoc reports can be run, this may prove less useful.

Adding such a check is pretty straightforward. Consider this policy:

create policy wibble__select
    on wibble
   for select
 using (veil2.i_have_global_priv(42));
      

To add logging on error, you can simply add a final or to the policy with a function call to a logging function (that always returns false), eg:

create policy wibble__select
    on wibble
   for select
   using (veil2.i_have_global_priv(42) or
          log_unwanted_access('wibble', <concatenation of key fields>));
      

Your logging function needs to take enough parameters to identify the record to which access has been attempted, must return false, and should identify the accessor by querying from veil2_session_context. Performance should not be a great concern as you expect the function to rarely be called.

While you are integrating Veil2 with your application and continuing to develop it, you are likely to create and drop your own database objects as they change. Be aware that through the veil2.accessors table and veil2.superior_scopes view, veil2 (and possibly other objects) is tightly coupled with your application schema.

This may mean that it is impossible to to drop some of your database objects because Veil2 database objects depend on them. Using the cascade option to drop will allow the drop to proceed but will result in dependent Veil2 objects being dropped as well. Recovering from this can be a tedious and potentially error-prone process.

We recommend avoiding the use of drop... cascade and instead scripting a drop and rebuild process that will explicitly deal with each dependent object. By making each drop explicit you can ensure that you correctly manage the re-building of those objects.


Prev  Up  Next
Chapter 23. How Veil2 Relates to the Original Veil  Home  Chapter 25. Performance