Heikki Linnakangas wrote: > KaiGai Kohei wrote: >> Tom Lane wrote: >>> KaiGai Kohei <kai...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
