From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: KaiGai Kohei <kaigai@kaigai.gr.jp>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Date: Mon, 20 Apr 2009 08:43:48 +0300
Message-ID: <49EC0B94.6070107@enterprisedb.com> (raw)
In-Reply-To: <49EBC588.4090807@ak.jp.nec.com>
References: <49E809F6.8070008@ak.jp.nec.com>
<49E8133A.7090601@enterprisedb.com>
<49E81EA1.2060202@ak.jp.nec.com>
<20069.1239977115@sss.pgh.pa.us>
<49E91AE4.9020404@kaigai.gr.jp>
<49E974AD.3020602@enterprisedb.com>
<13982.1240056219@sss.pgh.pa.us>
<49E9D5B6.9050406@enterprisedb.com>
<49EA7E4D.6060109@kaigai.gr.jp>
<49EAD5A6.4010601@enterprisedb.com>
<49EADF16.3050400@kaigai.gr.jp>
<12899.1240152674@sss.pgh.pa.us>
<49EBC588.4090807@ak.jp.nec.com>
KaiGai Kohei wrote:
> Tom Lane wrote:
>> KaiGai Kohei <kaigai@kaigai.gr.jp> writes:
>>> The vanilla access control mechanism switches the current userid, and it enables
>>> to run SELECT FOR SHARE without ACL_UPDATE, but SELinux's security model does not
>>> have a concept of ownership.
>> Should I not read that as "SELinux's security model is so impoverished
>> that it cannot be useful for monitoring SQL behavior"? If you don't
>> understand current user and ownership, it's hopeless. Trying to
>> distinguish SELECT FOR UPDATE instead of that is a workaround that is
>> only going to fix one symptom (if it even works for this, which I doubt).
>> There will be many more.
>
> It is a difference between two security designs, characteristics and
> philosophies, not a competitive merit and demerit.
> SELinux makes its decision based on the security policy and the security
> context of client and objects accessed. Here, user identifier and object
> ownership don't appear.
> Meanwhile, the vanilla PostgreSQL makes its decision based on the user
> identifier and database ACLs of objects accessed. It does not use the
> security context, needless to say.
Can't you have a SE-PostgreSQL policy like "disallow ACL_UPDATE on table
X for user Y, except when current user is owner of X"?
--
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, kaigai@kaigai.gr.jp
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
In-Reply-To: <49EC0B94.6070107@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