KaiGai Kohei wrote:
> When we create a new object, we can provide an explicit security context
> to be assigned on the new object, instead of the default one.
To get started, do we really need that feature? It would make for a
significantly smaller patch if there was no explicit security labels on
objects.
>>> On the other hand, the default PG model allows to bypass checks on
>>> certain objects. For example, column-level privileges are only checked
>>> when a user does not have enough permissions on the target table.
>>> If "SELECT a,b FROM t" is given, pg_attribute_aclcheck() may not invoked
>>> when user has needed privileges on the table t.
>> Hmm, I see. Yes, it does seem like we'd need to change such permission
>> checks to accommodate both models.
>
> I'm not clear why we need to rework the permission checks here.
> DAC and MAC perform orthogonally and independently.
> DAC allows to override column-level privileges by table-level privileges
> according to the default PG's model. It seems to me fine.
> On the other hand, MAC checks both of permissions. It is also fine.
I meant we need to refactor the code doing the permission checks. The
existing checks are doing the right thing for DAC, but as you point out,
if the MAC checks are within pg_*_aclcheck() functions,
pg_attribute_aclcheck() needs to be called even if you have privilege on
the table.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com