Stephen Frost wrote:
> * Gregory Stark (stark@enterprisedb.com) wrote:
>> It does seem weird to simply omit records rather than throw an error and
>> require the user to use a where clause, even if it's something like WHERE
>> pg_accessible(tab).
>
> It is weird from an SQL perspective, I agree with you there. On the
> other hand, it's what the security community is looking for, and is
> what's implemented by other databases (Oracle, SQL Server...) that
> do row-level security and security labels. Requiring a where clause
> or you throw an error would certainly make porting applications that
> depend on that mechanism somewhat difficult, and doesn't really seem
> like it'd gain you all that much...
It seems to me that there are two different standards to which this feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some specific applications so long as you're careful to
avoidcrafting policies that produce bizarre behaviors (like avoiding restricing access to foreign key data you
mightneed). On the other hand it gives you enough rope to hang yourself and produce weird results that don't
makesense from a SQL standard point of view if you aren't careful matching the SEPostgres rules with your apps.
or
b) SEPostgreSQL should only give enough rope that you can not craft rules that produce unexpected behavior from a
SQLpoint of view; and that it would be bad if one can produce SEPostgres policies that produce unexpected SQL
behavior.
It seems to me many of the security-enhanced products seem to
do the former; while it seems some of the objections to this
patch are more of the latter.