Message-ID: <49EC198F.6090604@ak.jp.nec.com>
Date: Mon, 20 Apr 2009 15:43:27 +0900
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, KaiGai Kohei <kaigai@kaigai.gr.jp>,
	pgsql-hackers@postgresql.org
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
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>
	<49EC0B94.6070107@enterprisedb.com>
In-Reply-To: <49EC0B94.6070107@enterprisedb.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Heikki Linnakangas wrote:
> 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"?

It seems to me a quite ad-hoc idea.
At least, it can prevents several users (with individual security contexts)
to share a common read-writable table, even if both of the kernel security
policy and vanilla database ACL allow it.
Now we can discriminate them using rte->modifiedCols. I don't find out any
problem in this approach. It can solve my headach without any changes in
the vanilla database ACLs.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>