From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE |
Date: | 2009-04-20 06:43:27 |
Message-ID: | 49EC198F.6090604@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)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(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-04-20 06:52:05 | Re: Patch for 8.5, transformationHook |
Previous Message | Peter Eisentraut | 2009-04-20 06:29:45 | Re: Unicode support |