Re: proposal: hide application_name from other users - Mailing list pgsql-hackers

On Tue, Jan 21, 2014 at 12:31 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>
> On 01/21/2014 04:19 PM, Heikki Linnakangas wrote:
> > On 01/21/2014 07:22 AM, Harold Giménez wrote:
> >> First of all, I apologize for submitting a patch and missing the
> >> commitfest
> >> deadline. Given the size of the patch, I thought I'd submit it for your
> >> consideration regardless.
> >>
> >> This patch prevents non-superusers from viewing other user's
> >> pg_stat_activity.application_name.  This topic was discussed some time
> >> ago
> >> [1] and consequently application_name was made world readable [2].
> >>
> >> I would like to propose that we hide it instead by reverting to the
> >> original behavior.  There is a very large number of databases on the same
> >> cluster shared across different users who can easily view each other's
> >> application_name values.  Along with that, there are some libraries that
> >> default application_name to the name of the running process [3], which
> >> can
> >> leak information about what web servers applications are running, queue
> >> systems, etc. Furthermore leaking application names in a multi-tenant
> >> environment is more information than an attacker should have access to on
> >> services like Heroku and other similar providers.
> >
> > I don't find these arguments compelling to change it now. It's
> > well-documented that application_name is visible to everyone. Just don't
> > put sensitive information there.
> >
> > For those users that don't mind advertising application_name, the patch
> > would be highly inconvenient. For example, the database owner could no
> > longer see the application_name of other users connected to her database.
>
> It also means that monitoring tools must run as superuser to see
> information they require, which to me is a total showstopper.


Well, the fact is that if you don't run monitoring tools as superuser,
there may not be enough connection slots available anyways, in cases
where actual usage is consuming all of max_connections, and only the
reserved slots are available. So in a way it's already unreliable to
run monitoring as non-superuser unfortunately.

>
>
> If you want control over visibility of application_name, it should be
> done with a column privilige granted to a system role, or something like
> that - so the ability to see it can be given to "public" on default
> (thus not breaking BC) and if it's revoked from "public", given to roles
> that need to see it.


Something along these lines sounds like would solve the problem.