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 1sMSEn-002UmG-Dv for pgsql-general@arkaria.postgresql.org; Wed, 26 Jun 2024 12:59:01 +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 1sMSEl-004Na1-RJ for pgsql-general@arkaria.postgresql.org; Wed, 26 Jun 2024 12:59:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMSEl-004NZt-Hp for pgsql-general@lists.postgresql.org; Wed, 26 Jun 2024 12:58:59 +0000 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sMSEj-003eYr-Mf for pgsql-general@lists.postgresql.org; Wed, 26 Jun 2024 12:58:59 +0000 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-25cae7464f5so3381787fac.3 for ; Wed, 26 Jun 2024 05:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719406735; x=1720011535; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MYwboYzefsHFQcKlxD1niQ4npEj+cO0DYpIIoaU9G/w=; b=E3p1CdGIVtD00lhgDa2zrJfkk4hHXpRBjC6a7GdsjTc8HIz2ccXzB9Lm+dqQn+HOgs nvh2LaBjmvqN7x/jG7jmeblCSIGbuAOOdlibcSlM03CsM+Wn9blPMxLdgyS259caPlbH mh6ZyfwFjEw2UPT6bctZW36YAhWXwQTdQKmKbPCKZjyMKbQf3vXPfO33/mMiYQgfVHIR ggkCHgagxKbSzrWEAhF5F9Dw6euzq5ispppuEv6qnmtvaazAoR7fbrbW6tQ7/72DIKFM 2IgwKEx2+dwOxwRGNq4q+GUfX0G8engYnBYdyyV7IBx77/FMCghO1Yo32lyt616JX+JB pLtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719406735; x=1720011535; h=content-transfer-encoding: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=MYwboYzefsHFQcKlxD1niQ4npEj+cO0DYpIIoaU9G/w=; b=RddF7WCfmceV0+RbxSOHLcG8QKpAr7Fxj3xI4ietBp8UnvSLwuWjCv5sYhUOu1NAfX o0QcT3KN1lNMQGpTopRK5wxgqKo4wJm4HrAN6z2Ynts0tS+rNt+6qxvZk3hABNnV0sU+ u21OLvdQbqQ0NeVRyzhi01hzgdGcYemiT87OXNVF7l05s0BfT/weq50w/jZ5JnC9C/oM xDeUYXkDeYMYYmheerq/LfeqTrPPd4KQtKUmMsvEaR/2/lRx3tGL3iDbOtr6YB450fE2 EWIbxWWkH8HTeJhLvK9sI9vMNUPP/r25eUizaHV6USNbkO1BKWj07t50fCwxsxJTr930 clrA== X-Gm-Message-State: AOJu0Yx7j20Ydxgu3rvMCcU2jYKSzIcJBj/YRref1rBC1lLEXe/MWHcd C6VzSCr/IqiiTYcB4GqhtK7kNdl3FSbqOLzaayCMD3tVljMBJcbe1obNVxPghECMa0oCz/c4rZd M6NIstFI8D58thd8WHRvfKrEPvZ0= X-Google-Smtp-Source: AGHT+IEBOmjvhm78Zl3q0Bq+UpSIwWUsDV6t+y8CEftz4O/lzGrx/ZYsmlGPLjnivV9JL9axdtDVqWR1a0hE3B6vJ/c= X-Received: by 2002:a05:6871:727:b0:257:ea15:b72b with SMTP id 586e51a60fabf-25d06bc84dcmr11070986fac.9.1719406735635; Wed, 26 Jun 2024 05:58:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dominique Devienne Date: Wed, 26 Jun 2024 14:58:44 +0200 Message-ID: Subject: Re: current_role of caller of a DEFINER function To: "David G. Johnston" Cc: "pgsql-general@lists.postgresql.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jun 26, 2024 at 2:42=E2=80=AFPM David G. Johnston wrote: > On Wednesday, June 26, 2024, Dominique Devienne wro= te: >> Only session_user >> is representative of the caller, and reliable (modulo SUPERUSER and >> SET AUTHORIZATION, but that's a different story and kinda normal) > > Why can you not use session_user then? Hi. As I already wrote above, the current_role matters in our security mode= l. The LOGIN user (i.e. session_user) is used only for authentication to the DB and to connect. All other security concerns are on other app-maintained (NOLOGIN) roles, used for authorization. --DD