Application name patch - v2
in [PgSql]
|
Prev: Hot standby status
Next: per table random-page-cost?
From: Dave Page on 19 Oct 2009 10:44 On Mon, Oct 19, 2009 at 3:42 PM, Massa, Harald Armin <chef(a)ghum.de> wrote: > > Would'nt this also make sense for PostgreSQL? That is, when no environment > is set, and no SET-command is issued, that the application name becomes the > default? That needs to be set by the application. As discussed previously, there's no way for libpq to get at argv[0]. -- 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
From: Tom Lane on 19 Oct 2009 10:49 Stephen Frost <sfrost(a)snowman.net> writes: > * Tom Lane (tgl(a)sss.pgh.pa.us) wrote: >> I do agree with Peter's concerns about limiting the character set of the >> name string, and maybe there should be some sort of length limit too. > I was thinking we might just declare it of type 'name'.. 'name' wouldn't help, since it's pretty character-set-agnostic. Anyway this is a GUC not a table column. Thinking about it more, it should be sufficient if we can ensure that the value is in the database encoding; logging of statements will already cause pretty much any legal DB-encoded string to be written to the log, so if you have a problem with that then you've already got a problem to fix. This is no issue for an ordinary SET, but AFAIR we do not have a good story for handling non-ASCII stuff arriving within the initial connection request packet. It might be time to try to do something about that. Or we could just restrict those values to ASCII. 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: Dave Page on 19 Oct 2009 11:02 On Mon, Oct 19, 2009 at 3:49 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Stephen Frost <sfrost(a)snowman.net> writes: >> * Tom Lane (tgl(a)sss.pgh.pa.us) wrote: >>> I do agree with Peter's concerns about limiting the character set of the >>> name string, and maybe there should be some sort of length limit too. > >> I was thinking we might just declare it of type 'name'.. > > 'name' wouldn't help, since it's pretty character-set-agnostic. > Anyway this is a GUC not a table column. As a sidenote, in the stats part of this patch I did limit the length to NAMEDATALEN for the purposes of sizing the shared memory allocation, however it's otherwise unlimited in length. Practically that just means that like the current query, the application name may be truncated when viewed through pg_stat_get_activity(). > Thinking about it more, it should be sufficient if we can ensure that > the value is in the database encoding; logging of statements will > already cause pretty much any legal DB-encoded string to be written to > the log, so if you have a problem with that then you've already got > a problem to fix. Right - that's what I was saying to Peter earlier. That can of course be turned off though > This is no issue for an ordinary SET, but AFAIR we do not have a good > story for handling non-ASCII stuff arriving within the initial > connection request packet. It might be time to try to do something > about that. Or we could just restrict those values to ASCII. It would seem sensible to apply the same rule to the connection string and SET, if only for consistency (at least as far as application_name is concerned). I know that use of Japanese/Chinese characters in database names is not uncommon however, so restricting connection strings to ASCII in general might not go down well. -- 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
From: Pavel Stehule on 19 Oct 2009 11:09 2009/10/19 Stephen Frost <sfrost(a)snowman.net>: > * Pavel Stehule (pavel.stehule(a)gmail.com) wrote: >> Superuser permission could not be a problem. Simple security definer >> function can do it. > > Then you've defeated the point of making it superuser-only. no. Because when I write security definer function, then I explicitly allow an writing for some roles. When I don't write this function, then GUC is secure. Pavel > > I don't think that changing the app name deserves a warning, to be > perfectly honest. Â Notice should be sufficient. > > Â Â Â Â Thanks, > > Â Â Â Â Â Â Â Â Stephen > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkrceMsACgkQrzgMPqB3kihrpwCePXXJLxXIpvfHF0fMXbO6Pn94 > uJcAn2cnT97QNqeRW2coKRDZfWVKaXxz > =xvXs > -----END PGP SIGNATURE----- > > -- 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: Stephen Frost on 19 Oct 2009 11:27
* Pavel Stehule (pavel.stehule(a)gmail.com) wrote: > 2009/10/19 Stephen Frost <sfrost(a)snowman.net>: > > * Pavel Stehule (pavel.stehule(a)gmail.com) wrote: > >> Superuser permission could not be a problem. Simple security definer > >> function can do it. > > > > Then you've defeated the point of making it superuser-only. > > no. Because when I write security definer function, then I explicitly > allow an writing for some roles. When I don't write this function, > then GUC is secure. And what happens when those 'some roles' are used by broken applications? You don't get to say "make it superuser only" and then turn around and tell people to hack around the fact that it's superuser only to be able to use it. That's not a solution. Stephen |