Re: Row Level Security − leakproof-ness and performance implications
От | Robert Haas |
---|---|
Тема | Re: Row Level Security − leakproof-ness and performance implications |
Дата | |
Msg-id | CA+Tgmob2-5HjqgRYVdyg-oaY-h8Q=t=9UwWS+0=m1Tp_jLrDnQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Row Level Security − leakproof-ness and performance implications (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: Row Level Security − leakproof-ness and performance implications
|
Список | pgsql-hackers |
On Thu, Feb 28, 2019 at 11:14 AM Joe Conway <mail@joeconway.com> wrote: > > Although, and Joe may hate me for saying this, I think only the > > non-constants should be redacted to keep some level of usability for > > regular SQL errors. Maybe system errors like the above should be > > removed from client messages in general. > > I started down this path and it looked fragile. I guess if there is > generally enough support to think this might be viable I could open up > that door again, but I don't want to waste time if the approach is > really a non-starter as stated upthread :-/. Hmm. It seems to me that if there's a function that sometimes throws an error and other times does not, and if that behavior is dependent on the input, then even redacting the error message down to 'ERROR: error' does not remove the leak. So it seems to me that regardless of what one thinks about the proposal from a usability perspective, it's probably not correct from a security standpoint. Information that couldn't be leaked until present rules would leak with this change, when the new GUCs were turned on. Am I wrong? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: