Re: Bug: RLS policy FOR SELECT is used to check new rows
От | Laurenz Albe |
---|---|
Тема | Re: Bug: RLS policy FOR SELECT is used to check new rows |
Дата | |
Msg-id | 7c54eb3c1f3a1017414ce399fae2a247c513740c.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Bug: RLS policy FOR SELECT is used to check new rows (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Bug: RLS policy FOR SELECT is used to check new rows
|
Список | pgsql-hackers |
On Tue, 2023-10-24 at 15:05 -0400, Stephen Frost wrote: > On Tue, Oct 24, 2023 at 14:42 Robert Haas <robertmhaas@gmail.com> wrote: > > On Tue, Oct 24, 2023 at 1:46 PM Jeff Davis <pgsql@j-davis.com> wrote: > > > Perhaps the idea is that if there are constraints involved, the failure > > > or success of an INSERT/UPDATE/DELETE could leak information that you > > > don't have privileges to read. > > > > My recollection of this topic is pretty hazy, but like Tom, I seem to > > remember it being intentional, and I think the reason had something to > > do with wanting the slice of a RLS-protect table that you can see to > > feel like a complete table. When you update a row in a table all of > > which is visible to you, the updated row can never vanish as a result > > of that update, so it was thought, if I remember correctly, that this > > should also be true here. It's also similar to what happens if an > > updatable view has WITH CHECK OPTION, and I think that was part of the > > precedent as well. I don't know whether or not the constraint issue > > that you mention here was also part of the concern, but it may have > > been. This was all quite a while ago... > > Yes, having it be similar to a view WITH CHECK OPTION was intentional, > also on not wishing for things to be able to disappear or to not get saved. > The risk of a constraint possibly causing the leak of information is better > than either having data just thrown away or having the constraint not > provide the guarantee it’s supposed to … Thanks everybody for looking and remembering. I can accept that the error is intentional, even though it violated the POLA for me. I can buy into the argument that an UPDATE should not make a row seem to vanish. I cannot buy into the constraint argument. If the table owner wanted to prevent you from causing a constraint violation error with a row you cannot see, she wouldn't have given you a FOR UPDATE policy that allows you to perform such an UPDATE. Anyway, it is probably too late to change a behavior that has been like that for a while and is not manifestly buggy. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: