Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ryZsV-00GxwO-Ow for pgsql-general@arkaria.postgresql.org; Sun, 21 Apr 2024 16:17:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ryZsS-00F6NJ-Ff for pgsql-general@arkaria.postgresql.org; Sun, 21 Apr 2024 16:17:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ryZsQ-00F6NB-Pr for pgsql-general@lists.postgresql.org; Sun, 21 Apr 2024 16:17:16 +0000 Received: from wfout7-smtp.messagingengine.com ([64.147.123.150]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ryZsL-003wJ7-2d for pgsql-general@lists.postgresql.org; Sun, 21 Apr 2024 16:17:13 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.west.internal (Postfix) with ESMTP id CAF7F1C00101; Sun, 21 Apr 2024 12:17:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 21 Apr 2024 12:17:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1713716225; x=1713802625; bh=6GfTH2OP9eBER8BG9woJKmWrF4cHJr1V+lNVbo2YN90=; b= jvfQtIoxq4wlXW3Yl+9M8GXTO9CO3QcaFv9jsFpzk+XYFTaXpYEDTxwzLGPvmm7Y XbiCxGpCIcErTDwCvev2MzCC9pq6x7G47Jgu/iG1vGt82GQbxbFRkM4pZQFObOSc tZ3Xy3V4wI8WoN1SdIXMgOJhmNJqTWc7xUGfebXA56fGf7twGG5xj0n7Z3JMk0Fw MNKg/0XCTzOANgbq8A8yLNnRC1zswefv5zuoaFn8cAZTqn/7wbtiDd5bvCSW/h/l uhNtNTetyhtFWAMsJsi7IBnyuC23wKd08hGcMATr0Vl/sbhhJWsMew1WzeCNDBXC WsPyu3ZwgAmqirzbIEYfdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1713716225; x= 1713802625; bh=6GfTH2OP9eBER8BG9woJKmWrF4cHJr1V+lNVbo2YN90=; b=c ScgbRzAte5bj+UaD3iZVxR6jOac7Br9CDJZ//M2NAVma96zmKrjeg+sOw7tVP2bF ZOdiYtS9ryUl6hEScnAeyblYnue6So2CtNvYTFrxLNvJxtQ1z75dVuTLbvXs+Hpr VZth7FtVz7H3/rpsb5QLLOilCLO8R4RVAOsbdfsdYKFzzBmZjeeJUGHaNtNNn+xe q+xtuep6Pcjb8cyHq5UV1DJUfUTl2/ojuk6Z6q1tUnXHZj/kPHUGedHfo7OaJg6O 5lUI6ibzGLPz39Ocyx0QJ5mrxdinCYYhiZ60iLZtc0HvIMzn1mpn8qEBD+gQy31r 4Ce2nz4czq5yzc5QXl+QA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudekjedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvvehfhfgjtgfgse htkeertddtvdejnecuhfhrohhmpeetughrihgrnhcumfhlrghvvghruceorggurhhirghn rdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomheqnecuggftrfgrthhtvghrnhepvddvue ejtdefvdekledvgedthfeiudeiiedvudeiffdvvefhtdfgjeejtdetvdegnecuffhomhgr ihhnpehpohhsthhgrhgvshhqlhdrohhrghdprghmrgiiohhnrdgtohhmnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggurhhirghnrdhklhgr vhgvrhesrghklhgrvhgvrhdrtghomh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 21 Apr 2024 12:17:04 -0400 (EDT) Message-ID: <505c7395-7334-4f07-a6bc-4766ed40e060@aklaver.com> Date: Sun, 21 Apr 2024 09:17:03 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Logging statement having any threat? To: Lok P Cc: pgsql-general References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 4/21/24 02:35, Lok P wrote: > On Sat, Apr 20, 2024 at 10:02 PM Adrian Klaver > > wrote: > > > Have you tried?: > > https://www.postgresql.org/docs/current/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT > > " > log_statement (enum) > >    <...> > > The default is none. Only superusers and users with the appropriate SET > privilege can change this setting. > " > > Or > > https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-SET > > set_config ( setting_name text, new_value text, is_local boolean ) → > text > > > > > > Now when we reach out to the infrastructure team , they are > saying these > > variables(pg_cluster_log_statement,pg_instance_log_statement) were > > Where are those variables coming from? I can not find them in RDS or > Terraform docs. > > >  Thank You Adrian. > > Actually I was trying to understand if the auto_explain can only work > and help us see the slow sql statements in the log, only after we set > the "log_statement" parameter to non default values (like all, mod, ddl)? > > And what is the exact threat with the logging these queries , and i log_statement = 'mod' create role pwd_test with password 'test'; CREATE ROLE tail -f /var/log/postgresql/postgresql-16-main.log <...> 2024-04-21 09:04:17.746 PDT [9664] postgres@test LOG: statement: create role pwd_test with password 'test'; > think ,I got the point as you mentioned , having access to database > itself is making someone to see the object details, however do you agree > that in case of RDS logs are available through different mediums like > cloud watch, data dog agent etc , so that may pose additional threats as Aah, the joys of managed services where you have to check even more layers when building out your security. Logging itself is not the issue, who has access to the logs is. The more access points the more difficult that gets. Dealing with this is going to require a system wide review by all parties and coming up with an agreed upon access policy that balances security with the need to monitor what is happening in the database. Otherwise troubleshooting issues will be a long drawn out process which in itself could end up being a security issue. > because , may be some person doesn't have access to database directly > but still having permission to see the logs, so the appropriate access > control need to put in place? > > And additionally I was trying to execute the "SELECT > set_config('log_statement', 'all', true);" but it says "/permission > denied to set parameter "log_statement/".".So might be it needs a higher > privileged user to run it. > > To answer your question on the variable those we have on the > terraform module, the terraform module is customized by the database > infra team so that might be why we are seeing those there which may not > be exactly the same as its showing in RDS docs for postgres. > > https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.Concepts.PostgreSQL.html > -- Adrian Klaver adrian.klaver@aklaver.com