On Sat, Jan 25, 2014 at 10:42 AM, Greg Stark <stark@mit.edu> wrote:
On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander <magnus@hagander.net> wrote:
> What actually happens if you set the application_name in the connection > string in that environment? Does it override it to it's own default? If so, > the developers there clearly need to be taught about > fallback_application_name. > > And what happens if you set it in PGAPPNAME?
My point wasn't that an application couldn't control this. The point is that this isn't so easy to manage and users might not realize there's anything to do.
And it's not necessarily the case that the library could warn users. No one of the parts of the code here has the whole picture. In this case one part of the code is stuffing the information in $0 and another part is defaulting application_name to $0.
We still show the ip address. And the client port number. and the username. And the database. These may also give away information. No, not as much as if you stick a password into application_name for example, but they still give out information. Perhaps what you really would need is for pg_stat_activity to be *completely* superuser only? Because it *does* tell you about what other users are doing.
Now, actually having the ability to do that would be a good thing, because there are certainly environments where it might make sense. But that's back to the "long term solution" of actually making it configurable. Not cherry-picking which features should break for some users and not others.
> Long term I agree we should really have some way of controlling these > permissions more fine grained, but I just blanket hiding application name > for non-superusers seems like a bad solution that still only fixes a small > part of the problem.
It makes a lot of sense to me to treat it the same way as sql_query. It's pretty similar (especially in the above given that we put the sql query in $0 after all)
Except we *don't* put the SQL query in $0. We only put "SELECT" (or other commandtags), not the actual contents of the query. So *we* make sure we don't put the sensitive information there, since the wrong people may see it in argv, because that's our responsibility. Just like it's the responsibility of the client to make sure they don't put security sensitive information in application_name.
If we restrict application_name to superusers only this way, we punish those who *don't* do the wrong thing by requiring their monitoring to now use superuser, in favor of those who *do* the wrong thing, which is put security sensitive information in application_name.