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 1ryTcY-00GVKQ-An for pgsql-general@arkaria.postgresql.org; Sun, 21 Apr 2024 09:36:26 +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 1ryTcV-00DuU4-9w for pgsql-general@arkaria.postgresql.org; Sun, 21 Apr 2024 09:36:23 +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 1ryTcU-00DuQ8-7s for pgsql-general@lists.postgresql.org; Sun, 21 Apr 2024 09:36:22 +0000 Received: from mail-oo1-xc33.google.com ([2607:f8b0:4864:20::c33]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ryTcH-003tqn-AM for pgsql-general@lists.postgresql.org; Sun, 21 Apr 2024 09:36:14 +0000 Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-5acdbfa6e95so801437eaf.3 for ; Sun, 21 Apr 2024 02:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713692168; x=1714296968; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HcyV1KzB8yFm0UhCYW+/wWd8cgvBAEq2FHFeTp0ds5g=; b=IEy7zK2F5kPq10eqorzaDHCa0FNRg8f2muMiC1zpw+h8Ws6a4qkiN6U02YB5SOd74U KVDBohQRsfG1e2LBV9xi1z/PJr4JXf8wFw/4a6jXs+pC0XJ4sD9q6ryR5eHTi450Bp46 MBpKcyA85PNLk7v3OxPe6aBM8ZpopuO70PPRBldmVtRo9S//gMUzdgGvbuTmAPRZJ1JI FKplJwAFDmRpwtPUnqv14yA+HySV7B2gVVo7W4LVkgQUyq+0sCHb97chbygxthPLDiWs MtoVluVTz0u2j48nhP18BrzYpkTidzykg4CtZIA5Sf6dz+h+/+gmS8thHqqPxvOb4+Zq fzug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713692168; x=1714296968; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HcyV1KzB8yFm0UhCYW+/wWd8cgvBAEq2FHFeTp0ds5g=; b=gsL7yNKkMQXIHPEwLPANUzEK/Pg+tEBTiYWLgiOKuR0RakUUdvNXIDJp9UFLTqneEI gaGcXi/iLv6YP04CHEFyFWN917lir1AcnR8/ZVSeBc803te1zxg78xItpO95+tqvuAht NB9EQtPQysE2WJ6CUEhEmQraSUmqAuklic/zFnUN2c2fijuTE02tC1p8VMqxy7HPJj7u /LsZW5fTX1PGoI06voGl14wB1us9DrCLLWnd5Jku6VwhcOTadFhnErvkKBYWuDZiDUDA BmtY2aa9iHWzHm7I3oCHf7O5lOgLnVn3FFVkSNvO/YrVWub7msSpPjtJ4XnHTN2Nt1EC yrgA== X-Gm-Message-State: AOJu0YxOH6384/qdet+Pdl+S9RKn52URqH/6coMMUO013UZKNUbR+JGq aOiHSW3HSALPZ3SLobGWkN4SCsvRI+0qpG+PDUFoscABMQKpX00wrUewJUPv6ujODNByDRG/hLA JrOji1LSxE9LT8Wv/+cYtl70+t2twckXZ X-Google-Smtp-Source: AGHT+IEZjXNOsviKYFSI4lePiptO4XAp6esMzM4JQYU/Cdtx+mfosyF0hT7+6EB5qMRZLEXv38PNhc93TWx+NR34JNk= X-Received: by 2002:a05:6359:459a:b0:189:b439:8f12 with SMTP id no26-20020a056359459a00b00189b4398f12mr7715505rwb.3.1713692168348; Sun, 21 Apr 2024 02:36:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lok P Date: Sun, 21 Apr 2024 15:05:56 +0530 Message-ID: Subject: Re: Logging statement having any threat? To: Adrian Klaver Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000f2ec7d0616980c5d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f2ec7d0616980c5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 20, 2024 at 10:02=E2=80=AFPM Adrian Klaver wrote: > > Have you tried?: > > > https://www.postgresql.org/docs/current/runtime-config-logging.html#RUNTI= ME-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-AD= MIN-SET > > set_config ( setting_name text, new_value text, is_local boolean ) =E2=86= =92 text > > > > > > Now when we reach out to the infrastructure team , they are saying thes= e > > 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 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 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 --000000000000f2ec7d0616980c5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Apr 20, 2024 at 10:02=E2=80=AFPM = Adrian Klaver <adrian.klave= r@aklaver.com> wrote:

Have you tried?:

https= ://www.postgresql.org/docs/current/runtime-config-logging.html#RUNTIME-CONF= IG-LOGGING-WHAT

"
log_statement (enum)

=C2=A0 =C2=A0<...>

The default is none. Only superusers and users with the appropriate SET privilege can change this setting.
"

Or

https://www.postgres= ql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-SET

set_config ( setting_name text, new_value text, is_local boolean ) =E2=86= =92 text


>
> Now when we reach out to the infrastructure team , they are saying the= se
> 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.


=C2=A0Thank You Adr= ian.=C2=A0

Actually I was trying to understand=C2= =A0if the auto_explain can only work and help us see the slow sql statement= s in the log, only after we set the "log_statement" parameter to = non default values (like all, mod, ddl)?=C2=A0

And= what is the exact threat with the logging these queries , and i think ,I g= ot the point as you mentioned , having access to database=C2=A0 itself is m= aking 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 because , may be som= e person doesn't=C2=A0have access to database directly but still having= permission to see the logs, so the appropriate access control need to put = in place?

And additionally=C2=A0I was trying t= o execute the "SELECT set_config('log_statement', 'all'= ;, true);" but it says "permission denied to set parameter &qu= ot;log_statement".".So might be it needs a higher privileged = user to run it.

To answer your question on the var= iable those we have on the terraform=C2=A0module, the terraform module is c= ustomized=C2=A0by the database infra team so that might be why we are seein= g those there which may not be exactly the same as its showing in RDS docs = for postgres.