| From: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Marc Munro <marc(at)bloodnok(dot)com>, Rod Taylor <rod(dot)taylor(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Using views for row-level access control is leaky |
| Date: | 2009-10-23 11:04:29 |
| Message-ID: | 4AE18DBD.9010801@kaigai.gr.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
> On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei wrote:
>>> Also, we should presume that any function created with SECURITY DEFINER
>>> and created by a superuser would have plan security, so we don't need to
>>> annotate lots of old code to work securely. Annotating the built-in
>>> functions is a lot easier.
>> Sorry, what is happen if function is marked as "plan security"?
>
> I was suggesting an intelligent default by which we could determine
> function marking implicitly, if it was not explicitly stated on the
> CREATE FUNCTION.
How to handle a (corner) case when the function owner was changed to non
privileged user and its definition is replaced later?
Even if someone malicious gives leakage condition on the view, possible
leakable infotmation is restricted to where the owner of view can access.
So, it seems to me the security mark on views by owner are sufficient.
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | KaiGai Kohei | 2009-10-23 11:19:12 | Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363)) |
| Previous Message | Simon Riggs | 2009-10-23 10:48:51 | Re: Using views for row-level access control is leaky |