content-based access control (Re: views, access control, etc)

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.

I wish that all I had to do was code the records with the
owner UID, and slap a "select trigger" or rule on the table
that said effectively:  on a select, if record N has a user
code not matching the user code of the query connection,
suppress that record from the output stream. [We could get
more sophisticated than that, of course:  if (RSE) and
(group|user code) in (list)...]

Of course the privileged user (database owner or postgres)
would have to be exempt.  I'd like to see this suppression
mechanism work for COUNT and all other stats. In fact, to each
user, the table should look like it contains only that user's
data.  That would be truly cool.  Like a view, but rule-based.

I *could* write a canned UI that creates this kind of view
dynamically as it starts up, but (imho) rules don't belong in
the app, they belong in the engine.  I want my access control
to be proof against C code using API lib, interactive sql
sessions, and any other way users can query the db.

So, is this "already in 6.3"?  Has anyone faced this problem
and solved it by various other clever means?  I haven't
thought it through as clearly as I would like, so I'd be
interested to hear from those who have.

de

.............................................................................
:De Clarke, Software Engineer                     UCO/Lick Observatory, UCSC:
:Mail: de@ucolick.org | "There is no problem in computer science that cannot:
:Web: www.ucolick.org |  be solved by another level of indirection"  --J.O. :