From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.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 16:27:25 +0900
Message-ID: <4ADC14DD.1070504@ak.jp.nec.com> (raw)
In-Reply-To: <4ADC0EDE.9080406@enterprisedb.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>
<4ADC0EDE.9080406@enterprisedb.com>
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 <kaigai@ak.jp.nec.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: kaigai@ak.jp.nec.com, heikki.linnakangas@enterprisedb.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: <4ADC14DD.1070504@ak.jp.nec.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