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 28 Nov 2009 18:47 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: 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? (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. Comments? 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: Joshua Tolley on 28 Nov 2009 19:27 On Sat, Nov 28, 2009 at 06:47:49PM -0500, Tom Lane 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: > > 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? > > (While I'm looking at it, I wonder why client_addr and client_port > are similarly hidden.) I vote for showing it to everyone, superuser or otherwise, though I can't really say why I feel that way. > 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. Nothing I've written uses RESET ALL, but if it did, I expect it would be because whatever the connection was being used for in the past differs substantially from whatever I plan to use it for in the future, which seems a suitable time also to change application_name. I vote against GUC_NO_RESET_ALL. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
From: Andres Freund on 28 Nov 2009 19:51 On Sunday 29 November 2009 00:47:49 Tom Lane 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: > > 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 28 Nov 2009 20:34 On Sat, Nov 28, 2009 at 7:27 PM, Joshua Tolley <eggyknap(a)gmail.com> wrote: > On Sat, Nov 28, 2009 at 06:47:49PM -0500, Tom Lane 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: >> >> 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? >> >> (While I'm looking at it, I wonder why client_addr and client_port >> are similarly hidden.) > > I vote for showing it to everyone, superuser or otherwise, though I can't > really say why I feel that way. +1. >> 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. > > Nothing I've written uses RESET ALL, but if it did, I expect it would be > because whatever the connection was being used for in the past differs > substantially from whatever I plan to use it for in the future, which seems a > suitable time also to change application_name. I vote against > GUC_NO_RESET_ALL. +1 to this, too. ....Robert -- 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: Dave Page on 29 Nov 2009 12:00
On Sat, Nov 28, 2009 at 11:47 PM, 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: > > 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |