On Sunday 29 November 2009 00:47:49 Tom Lane 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? I personally would prefer if it were not protected and explicitly documented as such - I cant really see a use case where one would want to store something really private in there.
> (While I'm looking at it, I wonder why client_addr and client_port > are similarly hidden.) In a shared hosting environment this is somewhat sensible - afair some data protection laws even require that nobody except the designated receiver of information is able to get that information. Whether shared hosting is sensible is another matter. > 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. One possibility would be to make it possible to issue SETs that behave as if set in a startup packet - imho its an implementation detail that SET currently is used. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
