Re: How to get SE-PostgreSQL acceptable

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