Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

Tom Lane wrote:
> 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.

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.

At the begining, I considered that SE-PostgreSQL want ACL_SELECT_FOR_UPDATE
to have individual bit other than ACL_UPDATE, but I also considered it should
not add user visible changes in the vanilla access controls, so the first
proposition changed only internal representation without new user visible
permissions (it was still checked as UPDATE privilege).

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>