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.

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.

 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to