Re: Reworks for Access Control facilities (r2363) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Reworks for Access Control facilities (r2363)
Date
Msg-id 4ADC0EDE.9080406@enterprisedb.com
Whole thread Raw
In response to Re: Reworks for Access Control facilities (r2363)  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: Reworks for Access Control facilities (r2363)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: postgres 8.3.8 and Solaris 10_x86 64 bit problems?
Next
From: "Albe Laurenz"
Date:
Subject: Re: Rejecting weak passwords