From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: robertmhaas@gmail.com
Cc: pgsql-hackers@postgresql.org
Cc: kaigai@kaigai.gr.jp
Subject: Re: Reworks for Access Control facilities (r2363)
Date: Fri, 16 Oct 2009 12:37:10 +0300
Message-ID: <4AD83EC6.2080800@enterprisedb.com> (raw)
In-Reply-To: <4AD7CCDD.1070402@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>
KaiGai Kohei wrote:
> The purpose of this patch is to provide function entrypoints for the
> upcoming SE-PostgreSQL feature, because I got a few comments that we
> hesitate to put sepgsql_xxx() hooks on the main routines directly in
> the first commit fest. In addition, I already tried to put SE-PG hooks
> within pg_xxx_aclchecks() in this CF, but it was failed due to the
> differences in the security models.
Can you elaborate that? It might well be that you need to adapt the
SE-PostgreSQL security model to the one that's there already. Putting
SE-PG hooks into existing pg_xxx_aclcheck functions is the only
low-impact way I can see to implement SE-PostgreSQL.
>> * There are two special-purpose shims, ac_database_calculate_size and
>> ac_tablespace_calculate_size, that got added for the benefit of
>> utils/adt/dbsize.c. What if that code were still in contrib? How is it
>> different from a lot of the code that is in contrib now, eg dblink or
>> pgrowlocks, to say nothing of third-party modules? Presuming that the
>> shim layer can know explicitly about each individual permission-checking
>> requirement is a dead-end design.
>
> Back to the definition of access controls (or reference monitor).
> It prevents violated accesses launched by user's requests (SQL).
> It is not a job to protect something from malicious internal modules.
The issue isn't malicious modules, but modules that have pg_xxx_aclcheck
calls in them and haven't been modified to do SE-pgsql checks like you
modified all the backend code. As the patch stands, they would perform
just the regular acl checks and bypass SE-pgsql.
--
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, tgl@sss.pgh.pa.us, sfrost@snowman.net, robertmhaas@gmail.com, kaigai@kaigai.gr.jp
Subject: Re: Reworks for Access Control facilities (r2363)
In-Reply-To: <4AD83EC6.2080800@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