Re: Information of pg_stat_ssl visible to all users
| От | Magnus Hagander |
|---|---|
| Тема | Re: Information of pg_stat_ssl visible to all users |
| Дата | |
| Msg-id | CABUevEw3mnirymSs0FtMS6b6FpUtQjX63=b7WS631GaDTw-sLg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Information of pg_stat_ssl visible to all users (Michael Paquier <michael.paquier@gmail.com>) |
| Список | pgsql-hackers |
<p dir="ltr"><br /> On Sep 1, 2015 4:37 AM, "Michael Paquier" <<a href="mailto:michael.paquier@gmail.com">michael.paquier@gmail.com</a>>wrote:<br /> ><br /> > On Tue, Sep 1, 2015at 4:23 AM, Peter Eisentraut <<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>> wrote:<br /> > > On 8/31/159:13 AM, Andres Freund wrote:<br /> > >> I'm just saying that we should strive to behave at least somewhat<br/> > >> consistently, and change everything at once, not piecemal. Because the<br /> > >> latterwill not decrease the pain of migrating to a new model in a<br /> > >> relevant way while making the systemharder to understand.<br /> > ><br /> > > Well, we already hide a fair chunk of information from pg_stat_activity<br/> > > from unprivileged users, including everything related to the connection<br /> > > originof other users. So from that precedent, the entire SSL<br /> > > information ought to be considered privileged.<br/> ><br /> > That being said we may want as well to bite the bullet and to hide<br /> > more informationin pg_stat_activity, like datname, usename and<br /> > application_name, or simply hide completely those tuplesfor<br /> > non-privileged users.<br /><p dir="ltr">That's likely to break every single monitoring tool ever writtenfor postgresql... <p dir="ltr">We're going to have to do that eventually, but I think we should wait until we havea complete solution (which would be either column permissions, monitoring role, or something like that (or combinationthereof)). <p dir="ltr">/Magnus
В списке pgsql-hackers по дате отправления: