Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kTocL-0007Re-TV for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Oct 2020 15:59:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kTocK-0004Tv-SA for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Oct 2020 15:59:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kTocK-0004To-LT for pgsql-hackers@lists.postgresql.org; Sat, 17 Oct 2020 15:59:36 +0000 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kTocH-000665-Vf for pgsql-hackers@lists.postgresql.org; Sat, 17 Oct 2020 15:59:36 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id A2245DF9; Sat, 17 Oct 2020 11:59:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 17 Oct 2020 11:59:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=DR4ACWENu/jXW/Gbd c7muhA0SS9yUHf8x7YMBnGwQIk=; b=V0ljMR6vl4jnOWIKcY08MTQDfzGWyWOLQ lExDpdPkWw2Vf83oUUD1ZiWxXo87pBea9P/kQ13+JIUVS9CT8NoS+tG9+NJJZQtm rpio9wL29mQDin7YPgAlXoxHZz/g16/++gPuR4MXoBo+wGjjBuVY8KBBGknMZAq8 EO3imzDo6BB8QmdjmavA52c9MpuIlkMfx1N2z+7LrQWvLcnq2jmutx2t0Z3L1/D5 W8FKJORDGqp6uSLOUfrSSHiKddvMlmXqNb66grSDGaaWcltSqIZ213Zilza+QhHl jlg0B0waiChggWcPnHv9N9MzAdYSFc0pI+ElDYPYQDkHICiUSaYrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieejgdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtuggjfgesthdtredttdervdenucfhrhhomheptehlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqne cuggftrfgrthhtvghrnhepvefgleevgeeujeeghfegteeghfegheeifeehheelteetiedu ieeihffggfehffetnecukfhppeduledtrdelhedrudelrddugeeknecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhv hhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.148]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C8CE328005A; Sat, 17 Oct 2020 11:59:28 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 5E5172A14CB; Sat, 17 Oct 2020 12:59:26 -0300 (-03) Date: Sat, 17 Oct 2020 12:59:26 -0300 From: Alvaro Herrera To: Julien Rouhaud Cc: Tom Lane , Bruce Momjian , Robert Haas , Michael Paquier , torikoshia , Atsushi Torikoshi , Tatsuro Yamada , Tomas Vondra , Evgeny Efimkin , PostgreSQL Hackers Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? Message-ID: <20201017155926.GA11995@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Oct-17, Julien Rouhaud wrote: > On Sat, Oct 17, 2020 at 12:23 AM Tom Lane wrote: > > then there's a potential security issue if the GUC is USERSET level: > > a user could hide her queries from pg_stat_statement by turning the > > GUC off. So this line of thought suggests the GUC needs to be at > > least SUSET, and maybe higher ... doesn't pg_stat_statement need it > > to have the same value cluster-wide? > > Well, I don't think that there's any guarantee that pg_stat_statemens > will display all activity that has been run, since there's a limited > amount of (userid, dbid, queryid) that can be stored, but I agree that > allowing random user to hide their activity isn't nice. Note that I > defined the GUC as SUSET, but maybe it should be SIGHUP? I don't think we should consider pg_stat_statement a bulletproof defense for security problems. It is already lossy by design. I do think it'd be preferrable if we allowed it to be disabled at the config file level only, not with SET (prevent users from hiding stuff); but I think it is useful to allow users to enable it for specific queries or for specific sessions only, while globally disabled. This might mean we need to mark it PGC_SIGHUP and then have the check hook disallow it from being changed under such-and-such conditions.