Re: [pgsql-general] Daily digest v1.6578 (20 messages) - Mailing list pgsql-general

From Alexander Staubo
Subject Re: [pgsql-general] Daily digest v1.6578 (20 messages)
Date
Msg-id C244A12F-5014-46B5-9483-26882EFF20C6@purefiction.net
Whole thread Raw
In response to Re: [pgsql-general] Daily digest v1.6578 (20 messages)  (Marc Munro <marc@bloodnok.com>)
List pgsql-general
On Nov 6, 2006, at 21:00 , Marc Munro wrote:

> A fairly cursory look at your proposed model suggests that it will
> work,
> but is likely to have serious performance problems.  The issue is
> not so
> much the simple queries on single views, but the complex queries your
> developers will almost certainly build from them.  A three-table join
> becomes a nine-table join, and planner, optimiser and executor all
> have
> to work very hard at that point.

Agreed. That said, I think there are optimizations that could
ameliorate the situation by reducing the number of joins at the
expense of reads. For example, filtering at the row level using bit
masks would potentially incur more data reads by not being able to
leverage any indexes, but this overhead may not be of a concern if
the ratio of negatives (rows the caller is not permitted to read) is
small.

> I believe that with some rework, you could implement your proposed
> security model using Veil to good effect.  Veil records privileges,
> etc
> in shared and session memory and so determining whether the connected
> user can see row x requires no extra fetches from the database.

I would prefer to avoid tying myself to new and unproven third-party
software, but I'm interested in trying out Veil. From what I can see
it essentially implements a set of generic, efficient low-level
bitmap index and hash primitives that can be used to implement a
security framework such as ours. I like the fact that it does not, as
far as I can see, force you into a specific security model.

The demo app relies on views, rules and namespacing to implement
transparent security, which is not a direction I am interested in
going. It does look like you can pry this apart and use the functions
directly. My biggest concern is that the whole framework is pretty
much undocumented on the user side, and setting up even just a test
case would require a lot of source reading, testing and so forth just
to determine whether fits my own application.

Could you give me a brief overview of the architecture and an example
of a simplified bitmap setup?

Alexander.



pgsql-general by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: data does not exist :-(
Next
From: Alexander Staubo
Date:
Subject: Re: [pgsql-general] Daily digest v1.6578 (20 messages)