Re: Updates of SE-PostgreSQL 8.4devel patches

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
system.

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