Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
Date: 2009-04-19 14:51:14
Message-ID: 12899.1240152674@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> writes:
> Heikki Linnakangas wrote:
>> Why should it discriminate between them?

> Typically, we cannot set up a foreign-key which refers a primary-key within
> read-only table from SELinux's viewpoint.
> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-19 15:06:50 Re: to_timestamp() changes in 8.4 release notes
Previous Message Bernd Helmle 2009-04-19 14:36:43 Re: planner crash/assert hit in 8.4B1