Application name patch - v4
in [PgSql]
|
Prev: Backup history file should be replicated in Streaming Replication?
Next: [PATCH] hstore documentation update
From: Tom Lane on 29 Nov 2009 12:22 Dave Page <dpage(a)pgadmin.org> writes: > On Sat, Nov 28, 2009 at 11:47 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> 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'. OK. Everybody seems to agree it should not be hidden, so I'll go change that. >> 2. I am wondering if we should mark application_name as >> GUC_NO_RESET_ALL. > I think we should use GUC_NO_RESET_ALL. I agree with you, but it seems we have at least as many votes to not do that. Any other votes out there? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 29 Nov 2009 15:03 Hi, Le 29 nov. 2009 à 18:22, Tom Lane a écrit : >> I think we should use GUC_NO_RESET_ALL. > > I agree with you, but it seems we have at least as many votes to not do > that. Any other votes out there? Driven by the pooler use case (pgbouncer, even), I'd say RESET ALL should reset also the application name. And the connection value is not tied any more to something sensible as soon as you have pooling in there... Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 Nov 2009 18:25 Dimitri Fontaine <dfontaine(a)hi-media.com> writes: > Le 29 nov. 2009 � 18:22, Tom Lane a �crit : >>> I think we should use GUC_NO_RESET_ALL. >> >> I agree with you, but it seems we have at least as many votes to not do >> that. Any other votes out there? > Driven by the pooler use case (pgbouncer, even), I'd say RESET ALL should reset also the application name. And the connection value is not tied any more to something sensible as soon as you have pooling in there... The thing is that the libpq API treats application_name as a *property of the connection*. You shouldn't expect it to go away on RESET ALL, any more than you'd expect RESET ALL to cause you to be reconnected to some other database. If a pooler wants application_name to be cleared when it issues RESET ALL, I think it ought to be setting the name via SET, not via the libpq connection option. But it's certainly true that using GUC_NO_RESET_ALL would be a quick kluge rather than a proper solution. Andres Freund suggested upthread that we should fix this by extending SET: : 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. I think there's a good deal of merit in this, and it would't be hard at all to implement, seeing that we already have SET LOCAL and SET SESSION. We could add a third keyword, say SET DEFAULT, that would have the behavior of setting the value in a fashion that would persist across resets. I'm not sure that DEFAULT is exactly le mot juste here, but agreeing on a keyword would probably be the hardest part of making it happen. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Florian G. Pflug" on 29 Nov 2009 19:16 Tom Lane wrote: > : 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. > > I think there's a good deal of merit in this, and it would't be hard > at all to implement, seeing that we already have SET LOCAL and SET > SESSION. We could add a third keyword, say SET DEFAULT, that would > have the behavior of setting the value in a fashion that would > persist across resets. I'm not sure that DEFAULT is exactly le mot > juste here, but agreeing on a keyword would probably be the hardest > part of making it happen. Hm, but without a way to prevent the users of a connection pool from issuing "SET DEFAULT", that leaves a connection pool with no way to revert a connection to a known state. How about "SET CONNECTION", with an additional GUC called connection_setup which can only be set to true, never back to false. Once connection_setup is set to true, further SET CONNECTION attempts would fail. In a way, this mimics startup-packet SETs without actually doing things in the startup packet. best regards, Florian Pflug
From: Fujii Masao on 29 Nov 2009 20:01
On Sun, Nov 29, 2009 at 8:47 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Dave Page <dpage(a)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: Why doesn't application_name appear in postgresql.conf.sample? That is expected to be set from only libpq? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |