Simon Riggs wrote:
> I've argued that row security should apply to ALL commands by default.
> Which is exactly the same default as Oracle, as well as being the
> obvious common sense understanding of "row security", which does not
> cause a POLA violation.
>
> I have no objection to an option to allow row security to not apply to
> inserts, if people want that.
>
> I do object to the idea that row security for inserts/updates should
> only happen via triggers, which is an ugly and non-performant route,
> as well as complicating security.
In the software where I've seen this managed at an application
level, an address (for example) can be sealed by an update to the
"sealed" column or inserted with the sealed column set to true. I'm
not sure why you would want to allow one and not the other.
Now, I can envision a situation where it could make sense to use
the same predicate for limiting what a role could read and what a
role could write, but I'm not buying that that is more secure. In
fact, I see cases where you cannot achieve decent security without
the ability for both INSERT and UPDATE to write rows which security
excludes on reads. Functionally, I don't see anything which can't
be accomplished with just the read security and triggers.
I do agree that it would be nice if there were an easy way to
specify that the same predicate applies to both reads and writes.
I hope we can leave the syntax for this feature open to such
specification, even if the initial implementation only supports
limiting reads.
-Kevin