Heikki Linnakangas wrote: > 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.
The importance of the feature is relatively minor than MAC itself. So, I can agree to omit code corresponding to statement support from the first patch. (IIRC, about 300-400 lines can be reduced.) But it will be necessary feature at the next step, because DBA cannot create a special purpose table without statement support. For example, if security policy allows DBA to create read-writable table (in default) and read-only table. He cannot set up read-only table without explicit security label support. >>>> 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. I think we already learned refactoring DAC checks need widespread code changes and pushes a burden to reviewers. In this case, I think the point just after invocation of ExecCheckRTEPerms() in ExecCheckRTPerms() is the best point to put SE-PgSQL's checks. Needless to say, its specification should be clearly documented. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
