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"? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
