Re: [v9.4] row level security
От | Tom Lane |
---|---|
Тема | Re: [v9.4] row level security |
Дата | |
Msg-id | 1398.1378305956@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [v9.4] row level security (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [v9.4] row level security
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think it's entirely sensible to question whether we should reject (not >> "hold up") RLS if it has major covert-channel problems. > We've already had this argument before, about the security_barrier > view stuff, and that code got committed and is already released. So > the horse is already out of the barn and no amount of wishing will put > it back in. Well, the security-barrier view stuff did not present itself as a 100% solution. But perhaps more to the point, it was conceptually simple to implement, ie don't flatten views if they have this bit set, and don't push down quals into such sub-selects unless they're marked leakproof. > I haven't reviewed this patch in a long time, but I would > expect that it's basically just reusing that same infrastructure; in > fact, I'd expect that it's little more than syntactic sugar around > that infrastructure. I've not read it in great detail, but it isn't that. It's whacking the planner around in ways that I have no confidence in, and probably still wouldn't have any confidence in if they'd been adequately documented. regards, tom lane
В списке pgsql-hackers по дате отправления: