Application name patch - v2
in [PgSql]
|
Prev: Hot standby status
Next: per table random-page-cost?
From: Robert Haas on 19 Oct 2009 11:40 On Mon, Oct 19, 2009 at 10:36 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Dave Page <dpage(a)pgadmin.org> writes: >> On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >>> I thing, so change of original name should generate warning. > >> Well, if other people think that's necessary, it's certainly possible. > > I think Pavel's entire line of argument is utter nonsense. He's setting > up a straw man that has nothing to do with any actually likely use of > the variable. +1. I can't even understand why we're still arguing about this. Other than Pavel, everyone thinks this is a complete non-problem, and Pavel's hypothesis basically boils down to "someone might use this feature in a stupid and naive way". Well, sure. They might. So what? > 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 don't have a strong feeling about this. If limiting this to 7-bit characters solves some nasty encoding problems or something, then fine, but otherwise I think we can just escape what we emit into the log and say that users who log this information should have a sufficiently sophisticated log parser to cope with it. ....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: "Kevin Grittner" on 19 Oct 2009 11:53 David Fetter <david(a)fetter.org> wrote: > Could you point to a reference for this? It could help the rest of us > see what you're aiming for even better :) Sybase Adaptive Server Enterprise (ASE) clientapplname varchar(30) column in sysprocesses table: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.tables/html/tables/tables50.htm It can be set (for example) in the LOGINREC structure with DBSETLAPP: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc32600.1500/html/dblib/dblib18.htm SET clientapplname command to set on the fly by running SQL on the connection: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.commands/html/commands/commands85.htm -Kevin -- 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: "Kevin Grittner" on 19 Oct 2009 12:08 Robert Haas <robertmhaas(a)gmail.com> wrote: > Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> I think Pavel's entire line of argument is utter nonsense. > +1. I can't even understand why we're still arguing about this. Agreed. One premise of the whole concept was "don't even think of using it for security"[1]. That's not it's purpose; so any criticisms on that basis are irrelevant. Claims that it opens new security holes if you *don't* try to use it for this purpose don't seem to have any merit that I can see; I don't think Pavel has even attempted to put such an argument forward. -Kevin [1] http://archives.postgresql.org/message-id/407d949e0907161237r76ebd92av6836c6563d8a230e(a)mail.gmail.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 12:38 2009/10/19 Stephen Frost <sfrost(a)snowman.net>: > * 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. You don't understand me. When I would to have a secure environment, then I don't write this function. So there will not be a posibility to change application name from session. Pavel > > Â Â Â Â Stephen > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkrchUYACgkQrzgMPqB3kij8nACfUrF/wkpsORpXiN0QgbXvONdi > ghYAn19MpPNnRrf9BxmIOVBRR212JU6c > =c5tL > -----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: Magnus Hagander on 19 Oct 2009 16:34
2009/10/19 Dave Page <dpage(a)pgadmin.org>: > 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]. Um, that has to be platform dependent, no? On windows for example, you can use GetCommandLine(). -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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 |