Re: Updates of SE-PostgreSQL 8.4devel patches

From: Andrew Sullivan <ajs(at)commandprompt(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Date: 2008-10-09 14:01:34
Message-ID: 20081009140134.GB46922@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 08, 2008 at 11:36:19AM +0900, KaiGai Kohei wrote:
> Yes, unfortunatelly.
> No one replied to my proposed design:
> http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2

FWIW, I didn't know what to say about that proposal because I still
don't know what problems any of this is trying to solve. Perhaps I'm
just obtuse (and people should feel free to ignore me, since I'm not
volunteering any code anyway); but this entire discussion seems to me
to lack clear statements of what the goals of the effort are. I know,
"consistent access control"; that still doesn't tell me enough, I
think.

I haven't given it a great deal of thought, but it seems to me that
there are at least a few different goals people have in mind. These
are the ones I've thought of, but I don't pretend this is an
exhaustive list. It certainly isn't based on a serious review of the
literature, which seems to be plentiful:

1. Single-policy access control for all objects available in a
system. I'm guessing that this is the point of SE-PostgreSQL. It
also appears to me that the SE-Linux approach may not have completely
defined how these things work in a database context, but that there
has been academic work in this area. I think a clear description of
what the costs and benefits of this approach are would go a long way
to helping evaluation. For instance, what sort of side channels does
this expose? Are there database design techniques that help? &c.

2. Granular row-level access control based on database-level ACLs. I
have formed the impression that there is some support of this sort
needed anyway to implement (1), but maybe not. I guess this is the
proposal you mention. What is the goal here? Simply
administrator-defined controls on data access inside the database? Is
there a model we're following, or are we making one up? If the
latter, are we sure we're solving all the use cases? What are they?
What are the problems here: for instance, this has exactly the same
sorts of foreign-key issues that swamped the discussion of the
SE-PostgreSQL patches, and I don't see that the new proposal addresses
any of that.

3. Column-level access controls. This is ruled out of the current
discussion in the proposal mentioned above. Surely you need
column-level access controls to make (1) work, though? If not, then
I'm even more confused than I thought.

4. Metadata-level access controls. None of the proposals so far seem
to provide a complete set of access controls for the system details --
schemas, databases, &c. Such controls are often requested, so I
wonder about that.

Please understand that I'm not trying to be obstructive, but at the
moment I don't understand what the proposals aim to do. I suggest
that, without some clear statements of what things are trying to do,
and what the intended limitations are, it will always be impossible
for anyone to review the implementation of such a big feature and say
whether it does what it intends to do.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Sullivan 2008-10-09 14:21:55 Re: Updates of SE-PostgreSQL 8.4devel patches
Previous Message Peter Eisentraut 2008-10-09 13:52:40 Re: [WIP] plpgsql is not translate-aware