Skip site navigation (1) Skip section navigation (2)

Re: Updates of SE-PostgreSQL 8.4devel patches

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Date: 2008-09-26 02:09:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>>> This is just a different syntax for KaiGai's label storage
>>> implementation.  It doesn't really answer any of the hard questions,
>>> like what the heck is the behavior of foreign keys.
>> What do you find inadequate about KaiGai's answers to those hard questions?
> Mainly just that they're only one set of possible answers.  If we're
> thinking of baking a particular set of semantics into SQL syntax,
> we'd better be darn sure that they are the right semantics --- both
> in terms of widest usefulness, and in terms of not being stuck behind
> the eight-ball if the SQL standards committee ever moves to standardize
> a similar behavior.

If SQL standard adopts row-level security, it also welcomes for me.
Please note that SE-PostgreSQL works orthogonally from the native
access controls of PostgreSQL.
I think it is usefulness to apply different security policies based on
different rules, architecture and philosophy.

> Another point is that the proposed behavior leaks quite a lot of
> information, since it will fail operations on the basis of tuples that
> supposedly aren't visible to the invoking user.  While I admit that it's
> hard to see an alternative if we're to preserve FK integrity, I have to
> worry that this definition isn't going to satisfy the tin-foil-hat
> brigade that are supposed to be the main users of SEPostgres.  If the
> goal is "you don't know the row is there", this doesn't seem to meet it.

Yes, it is just a limitation of SE-PostgreSQL's row-level access control.
However, we can avoid actual matter by applying alternative keys for these
kind of databases, as Bruce mentioned before.
No need to say, it is a thing to be described in documentation,
and end-users should make their decison.

One considerable option provided to end-user is to add a switch called as
"boolean" to allow all of row-level access controls.

> I wonder whether it wouldn't make more sense to pursue restrictions
> at some different level.  SQL already has the concept of REFERENCE
> permission, ie, not just anybody can make a foreign key reference to
> your table.  Maybe there has to be a rule that you can't make an FK
> reference to a table you don't have full read permissions for.  The
> restrictions in the other direction (what can PK table's owner find out
> about FK table's contents) are pretty interesting too.

SE-PostgreSQL focuses on the fact client can see the PK refered.
It is different from native SQL's permission, but it think it is just a
difference between security models.

It is worthwhile to achieve secure state of databases in different levels.
For example, privileged database user can override all of access controls.
It is a unignorable risk, as root is considered as a risk in operating

OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2008-09-26 02:10:03
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Previous:From: Tom LaneDate: 2008-09-26 02:04:12
Subject: Bug in ILIKE?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group