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