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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
