From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, marc(at)bloodnok(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Fix leaky VIEWs for RLS |
Date: | 2010-06-07 12:56:21 |
Message-ID: | 20100607125621.GC21875@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Heikki Linnakangas (heikki(dot)linnakangas(at)enterprisedb(dot)com) wrote:
> WHERE should do it:
>
> SELECT * FROM secrets_view WHERE username = 'neighbor' AND
> password::integer = 1234;
> ERROR: invalid input syntax for integer: "neighborssecretpassword"
>
> Assuming that username = 'neighbor' is evaluated before the cast.
Fair enough, so we can't allow built-ins either, except perhaps in very
specific/limited situations. Still, if we track that the above WHERE
and password::integer calls *should* be run as "role X", while the view
should run as "role Y", maybe we can at least identify the case where
we've ended up in a situation where we are going to expose unintended
data. I don't know enough about the optimizer or the planner to have
any clue how we might teach them to actually avoid doing such, though I
certainly believe it could end up being a disaster on performance based
on comments from others who know better. :)
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-06-07 13:21:56 | warning message in standby |
Previous Message | Florian Pflug | 2010-06-07 12:10:30 | Re: Re: [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up |