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 1uMTip-00Cwhr-56 for pgsql-general@arkaria.postgresql.org; Tue, 03 Jun 2025 15:38:39 +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 1uMTin-001d5J-7E for pgsql-general@arkaria.postgresql.org; Tue, 03 Jun 2025 15:38:37 +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 1uMTim-001d5B-Sj for pgsql-general@lists.postgresql.org; Tue, 03 Jun 2025 15:38:37 +0000 Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uMTil-0001Y1-2Z for pgsql-general@lists.postgresql.org; Tue, 03 Jun 2025 15:38:36 +0000 Received: by mail-ot1-x332.google.com with SMTP id 46e09a7af769-736ef1ccb85so645115a34.1 for ; Tue, 03 Jun 2025 08:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748965115; x=1749569915; 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=iZStGiC3Au8UkNQo91cbEX6wwR373GURE760CJYORZ0=; b=grN9kkNCVYe8peS47K/liU174yufW8RmMhLmqLTIkIj7HprANN2Gp7FYilDSbHg3T/ NqeohGwY0ZGO3L2qJZ7dYToibZmHeEC8Ozz7eOm3pzVZo4SlH3BIkA1IQbCYg0NOvCCV 4H0kPvhOXa7mBJ6XPSCab5gVTI0Matpzfpi5HumbxopN5n/MI1JJcD44N/Y3h6NGI7OA /TkMveDkMgEXhFFVbc3d8Mfc0dbGDvJKxW9dAJJEYJ17NulFDbVWXWv63h0qbX3JfcD0 wW81n37C/gSLBizsz7uICei56TqVp5s56HqDtRttfLxTbevxZt+1sf1OBSZoqfqw7hNf VZLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748965115; x=1749569915; 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=iZStGiC3Au8UkNQo91cbEX6wwR373GURE760CJYORZ0=; b=F3k++92ggZ7+wEMvrO5Bst/Bh70Bg+b1qYDFpKZUtYEHggNzz6tXzyYHuAjYBdY45Z K5l0hO3eRfjjdzEi71VMBj8juvhXEHS+3o2Tq4+l0aaTUk9N/XD7hNm7AFQ8bkyNzDnM WUBrKv7BSLIha6w4jYTdYkgINeNerN74h0jVHqjIokeJ4BBIsSon4znqvMggm0HA/3qD GQNmR8BA3AQbTRuEPgcAQGePMZV/1v4cz00jAkCevKL7WMQPi8egWqYxk/dzmRPauf8T hKWXAXSEyRAOeUzl5MPSaShwvHWwVm+0GnxAHK67mtLS13cArk8Oodr5HtUYS2JwOwMZ qXeg== X-Gm-Message-State: AOJu0YysUyPjOqDomxENmHoQlgkS8WLI/EpzfSTeHI1qnPA7OaaIMopH qrq6V6pm/SLpdhI2uLGt0AIxQ5jWQCNWz8aQ6vbZt6GH7SDwVEJBcNy7IngV9cgUagLxN3mVcuf sRW+ESW3jUikuoH+k0lmtwwtzYqJMJ2QCLw== X-Gm-Gg: ASbGncuycOxAK1HBrzl7wGFVxAQY/4DP0yK5YuhBPjgPI3mX72I6UMH6TrlcdTLCe/w NPqCIGWaWXoRTwhSU9Ug9mFWFHMMLJ6qdMaZp+qia3XoEQTYIczjOvepdM0PW+xJNGJ3N7Xr6zt PDKs+1zbZp4SMziTQf8WiQtRsHKdHvVchTvsoqJL5JKtGMmA== X-Google-Smtp-Source: AGHT+IFyo0RaH3J84JCJvoxJisV7umgaSII9R5zT0IP8+Csswrlu1QiiX756CGPP4t+EXc08XIe/cFo29YV8O3iiT2s= X-Received: by 2002:a05:6870:1cd:b0:2e9:3c7:1a1a with SMTP id 586e51a60fabf-2e948193dc6mr6924875fac.0.1748965114728; Tue, 03 Jun 2025 08:38:34 -0700 (PDT) MIME-Version: 1.0 References: <0b7d3b22-3e98-4eca-bc14-9430c48c0217@technowledgy.de> In-Reply-To: From: Dominique Devienne Date: Tue, 3 Jun 2025 17:38:23 +0200 X-Gm-Features: AX0GCFvdZI3kIIl4uUOE-yvom_av_bi9OswOVhJblsfFP3FPd5q4Nz1Db3jBmpg Message-ID: Subject: Re: current_role of caller of a DEFINER function To: walther@technowledgy.de 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:25=E2=80=AFPM Dominique Devienne wrote: > On Wed, Jun 26, 2024 at 11:08=E2=80=AFAM Laurenz Albe wrote: > > On Wed, 2024-06-26 at 10:35 +0200, Dominique Devienne wrote: > > > So I have two questions: > > > 1) Is there any way to know the current_role of the caller of a > > > DEFINER function. I fear the answer is no, but better be sure from > > > experts here. > > > > Just to be certain, let me ask a question back: > > > > If a SECURITY DEFINER function calls another SECURITY DEFINER function, > > which role would you like to get: > > 1. the invoker that called the 1st function > > 2. the owner of the 1st function (which is the user that called the 2nd= function) > > Honestly Laurenz, I didn't think about it, and it does not matter too > much in my case. > Because what matters to me is the initial entry-point, from caller to > DEFINER function, > to accurately capture the role, and then I can pass it on explicitly > myself if needed. > This is for more knowledgeable people to decide on. Hi. Resurrecting this thread, 1 year later, to follow up on Laurenz question, and ask another of my own. It just so happens that I now have two layers of SECURITY DEFINER functions. The 1st (inner) layer is to encapsulate sensitive DDLs (and audit them), is one "DBA" schema that belong to a "DBA" role, that knows (almost) nothing of the application and is only concerned with pure-PostgreSQL stuff, and the 2nd (outer) layer more application specific, in another "App Admin" schema (that belongs to different ROLE yet). I'm using the DOMAIN type discussed here, on the outer layer, to capture the CURRENT_ROLE, i.e. the caller of that outer SECURITY DEFINER FUNCTION. This works great. But I also want to pass it down to the lower/inner layer, for auditing/logging purposes only. Initially I tried using the same DOMAIN type/value, but then I'd violate the CHECK constraints. The initial value was captured before entering the outer SECURITY DEFINER function, and when copying the value to pass it to the inner SECURITY DEFINER function, that value no longer matches the "new" CURRENT_ROLE from within the SECURITY DEFINER context. The work-around is to take it as text (or name) instead of the DOMAIN type, but that feels unsatisfactory, since then the caller could pass an arbitrary value, not something that comes from my DOMAIN type, which enforces the fact its value is the CURRENT_ROLE. So my question is whether my inner-procs can take another type, that can only be created from my DOMAIN type? I.e. I'd want to enforce the value I'm getting comes from my DOMAIN type, and only that type. Is that possible? Thanks, --DD