On Tue, Jan 21, 2014 at 7:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Craig Ringer (craig@2ndquadrant.com) wrote:
>>> 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.
>
>> I agree with this- individuals should be able to control access to this
>> information for their databases/clusters.
>
> I think that'd be much more complexity than the case justifies. The
> argument that application_name might contain sensitive information seems
> ludicrously weak to me: whatever a client is exposing as application_name
> is its own darn choice. If you don't like it, go fix the client.
> If there is some client library that sets application_name without
> allowing the choice to be overridden, then that's a problem with that
> library, not with the server's behavior.
I don't know of a client where it can't be overridden. The friction
occurs when by default it sets it to something useful to a developer
(useful eg: to find what process is holding a lock), but is not
possible to conceal from other users on the same cluster. If this were
an in-premise or private cluster the point is moot.
Furthermore consider when even using application_name for it's
original intended use. On a shared environment as I'm describing here,
that makes it possible for an attacker to identify what apps connect
to a given server, or on the other hand is a way to find out where a
given application stores its data, which can be used for a more
targeted attack.
Beyond that yes, it's definitely possible to fix the client, but the
cited is but one example of defaults people are using in the wild, and
if the trend continues we'll be facing fanout of this behavior. I feel
like being conservative and fixing the issue on the server side is
worthwhile.
Regards,
-Harold