Joshua Brindle wrote:
> > The big problem is that the security value on system tables controls the
> > _object_ represented by the row, while on user tables the security value
> > represents access to the row. That is just an odd design, and why a
> > regular system table security value makes sense, independent of the
> > row-level security feature.
> >
>
> I may not be understanding this but I don't see why. In SELinux everything is an
> object, and all objects have contexts. No access is specified on the object or
> in the context, that is all done in the policy currently loaded in the security
> server. system tables and user tables shouldn't be treated differently
> implementation wise, they should just have a context and defer the decision
> making to the policy.
>
> In practice the system tables (and rows within the tables) would have a context
> that restricts access tightly, but this is up to the policy, not the implementation.
>
> > FYI, it is possible we might implement row-level security a different
> > way in 8.5.
Seeing a pg_attribute row and seeing the column referenced by the row
are not the same thing.
Also, we are discussing system catalog values, (table, column,
function), etc, so I don't see an performance issue. I haven't heard of
anyone complaining about our ACL parsing overhead recently. A cache
could still be used, but on the text string, not the oid.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +