On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian <br...@momjian.us> wrote: > On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote: >> 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. > > So security through obscurity? Why wouldn't the attacker just try all > the app methods at once and not even bother looking at the application > name?
A malicious attacker may want to attack or harm `app1`. They write a script that provisions databases and check in pg_stat_activity until they find an application_name of `app1`. Having found the database holding app1's data, they then use a targeted attack on postgres, say a privilege escalation attack or any other vulnerability we don't know exists yet. Without application_name, the attacker would be unable to find the target database host to attack. -Harold -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
