De Clarke wrote:
>
> Seems like the discussion on views and access control is
> drifting in a direction that interests me. At the risk of
> once again bringing up an issue that's already been solved
> and tabled, I offer the following wish item:
>
> Content-based access control (CBAC). In my experience,
> when these words are uttered, DBAs and MIS designers groan.
> I wish CBAC were never required. Unfortunately sometimes
> it is, and I wonder if the PG team is thinking about it.
>
> Column protection is not CBAC, of course, though it sorta
> feels like it. Column protection can be useful, but I've
> had less need for it than true CBAC. I'd like to see
> column AC in PG someday, but it's not very important to me
> personally -- whereas I have immediate requirements for CBAC.
>
> In true CBAC, the whole record is confidential. In table T,
> User X "owns" some records and User Y "owns" some records, and
> the two of them should not see each other's records. You can
> address this problem with views (if your view mechanism allows
> RSE as well as FSE, and if views don't inherit AC from parent
> tables). But this gets you into a maintenance headache, where
> you're creating new views every time a new user joins the
> crowd.
>
> What I'd like, when I really think about it, is a rule
> mechanism for selects. Perhaps PG already has this, but my
> conceptual model is the Sybase trigger feature. On Update and
> Delete (but not select) in the older Sybase engines, the DB
> designer can interrupt the transaction and abort or alter it
> according to rules coded in SQL. This was *very* useful, but
> (at least back then) it didn't work on select.
You could use PG triggers on Updates, Deletes and Inserts (to insert
owner user name) and try to use RULEs to rewrite SELECT statement.
(I never played with RULEs...)
Vadim