Application name patch - v2
in [PgSql]
|
Prev: Hot standby status
Next: per table random-page-cost?
From: Pavel Stehule on 19 Oct 2009 04:23 2009/10/19 Dave Page <dpage(a)pgadmin.org>: > On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> I dislike write access to app name guc for user too. It's not safe. >> Maybe only super user can do it? > > That'll render it pretty useless, as most applications wouldn't then > be able to set/reset it when it makes sense to do so. But application can do it simply via connection string, no? Mostly applications has connection string in configuration, so I don't see problem there. And if I would to allow access, then I could to wrap setting to security definer function. I see this as security hole. It allows special SQL injection. Regards Pavel Stehule > > > -- > 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 04:29 2009/10/19 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com>: > Pavel Stehule wrote: >> 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >>> On Mon, Oct 19, 2009 at 8:37 AM, Peter Eisentraut <peter_e(a)gmx.net> wrote: >>>> So this would effectively allow any minimally authorized user to write >>>> whatever they want into the log file whenever they want? Â Doesn't sound >>>> very safe to me. >>> A user can do that anyway if query logging is turned on, but anyway, >>> what would you suggest - accept a-zA-Z0-9 and a few other choice >>> characters only, or just reject a handful (and if so, what)? >> >> I dislike write access to app name guc for user too. It's not safe. >> Maybe only super user can do it? > > The application name is provided by the client. In the server, we have > no control over what the client put there. We can limit it to certain > characters, but other than that we just have to take it at face value. > > Or are you saying that it should not be possible for the client to > change the value after connecting? That limits the usefulness with > connection pools. > What I know, connections from connection pool without reset are shared by one application. But I am not against some possibility to change this value from application. I am against to possibility an change by normal user. When we allow it, then this value has not any wight, because any broken appliaction (via SQL injection) can change it. Regards Pavel Stehule > -- > Â Heikki Linnakangas > Â EnterpriseDB Â 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: Dave Page on 19 Oct 2009 04:30 On Mon, Oct 19, 2009 at 9:23 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >>> I dislike write access to app name guc for user too. It's not safe. >>> Maybe only super user can do it? >> >> That'll render it pretty useless, as most applications wouldn't then >> be able to set/reset it when it makes sense to do so. > > But application can do it simply via connection string, no? Mostly > applications has connection string in configuration, so I don't see > problem there. And if I would to allow access, then I could to wrap > setting to security definer function. It will prevent an application changing the value before running a long operation which may warrant special identification. It will also prevent applications changing the setting if you're running through a pooler. > I see this as security hole. It allows special SQL injection. How so? -- 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 04:36 2009/10/19 Dave Page <dpage(a)pgadmin.org>: > On Mon, Oct 19, 2009 at 9:23 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >>> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >>>> I dislike write access to app name guc for user too. It's not safe. >>>> Maybe only super user can do it? >>> >>> That'll render it pretty useless, as most applications wouldn't then >>> be able to set/reset it when it makes sense to do so. >> >> But application can do it simply via connection string, no? Mostly >> applications has connection string in configuration, so I don't see >> problem there. And if I would to allow access, then I could to wrap >> setting to security definer function. > > It will prevent an application changing the value before running a > long operation which may warrant special identification. It will also > prevent applications changing the setting if you're running through a > pooler. Then we have to divide this value to two independent values like application_name and application_state. > >> I see this as security hole. It allows special SQL injection. > > How so? > You change identity. If any application is vulnerable to SQL injection, then this value is nice goal. Pavel > > > -- > 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: Andrew Dunstan on 19 Oct 2009 04:42
Pavel Stehule wrote: > 2009/10/19 Dave Page <dpage(a)pgadmin.org>: > >> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> >>> I dislike write access to app name guc for user too. It's not safe. >>> Maybe only super user can do it? >>> >> That'll render it pretty useless, as most applications wouldn't then >> be able to set/reset it when it makes sense to do so. >> > > But application can do it simply via connection string, no? Mostly > applications has connection string in configuration, so I don't see > problem there. And if I would to allow access, then I could to wrap > setting to security definer function. > > I see this as security hole. It allows special SQL injection. > > How is it any more a security hole than any other setting that the user can alter with an arbitrary string value (e.g. custom options)? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |