From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: robertmhaas@gmail.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: Reworks for Access Control facilities (r2363)
Date: Mon, 19 Oct 2009 10:01:50 +0300
Message-ID: <4ADC0EDE.9080406@enterprisedb.com> (raw)
In-Reply-To: <4ADBE437.1090002@ak.jp.nec.com>
References: <4AC5A14F.6050306@ak.jp.nec.com>
<20091012024604.GW17756@tamriel.snowman.net>
<4AD54082.9050001@ak.jp.nec.com>
<10495.1255627322@sss.pgh.pa.us>
<4AD7CCDD.1070402@ak.jp.nec.com>
<4AD83EC6.2080800@enterprisedb.com>
<4AD94806.9020802@kaigai.gr.jp>
<4AD9CC56.9090609@enterprisedb.com>
<4ADBE437.1090002@ak.jp.nec.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, kaigai@ak.jp.nec.com, kaigai@kaigai.gr.jp, tgl@sss.pgh.pa.us, sfrost@snowman.net, robertmhaas@gmail.com
Subject: Re: Reworks for Access Control facilities (r2363)
In-Reply-To: <4ADC0EDE.9080406@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox