On Sat, Nov 28, 2009 at 11:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dave Page <dp...@pgadmin.org> writes: >> Updated application name patch, including a GUC assign hook to clean >> the application name of any unsafe characters, per discussion. > > Applied with assorted editorialization. There were a couple of > definitional issues that I don't recall if we had consensus on: > > 1. The patch prevents non-superusers from seeing other users' > application names in pg_stat_activity. This seems at best pretty > debatable to me. Yes, it supports usages in which you want to put > security-sensitive information into the appname, but at the cost of > disabling (perfectly reasonable) usages where you don't. If we made > the app name universally visible, people simply wouldn't put security > sensitive info in it, the same as they don't put it on the command line. > Should we change this?
Uh, yeah, I guess. That wasn't a concious decision, more a copy n paste inherited 'feature'. > (While I'm looking at it, I wonder why client_addr and client_port > are similarly hidden.) > > 2. I am wondering if we should mark application_name as > GUC_NO_RESET_ALL. As-is, the value sent at libpq initialization > will be lost during RESET ALL, which would probably surprise people. > On the other hand, not resetting it might surprise other people. > If we were able to send it in the startup packet then this wouldn't > be a problem, but we are far from being able to do that. In the use cases I envisage for this, the appname is more a property of the connection than the session, thus I wouldn't expect it to change following a RESET ALL. That said, one could then argue that it should RESET to the connection-time value... I think we should use GUC_NO_RESET_ALL. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
