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 1sMPY7-002BeO-AT for pgsql-general@arkaria.postgresql.org; Wed, 26 Jun 2024 10:06:47 +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 1sMPY4-003ELd-QU for pgsql-general@arkaria.postgresql.org; Wed, 26 Jun 2024 10:06:45 +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 1sMPY3-003ELU-KJ for pgsql-general@lists.postgresql.org; Wed, 26 Jun 2024 10:06:44 +0000 Received: from mout-u-107.mailbox.org ([2001:67c:2050:101:465::107]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMPY0-003dFp-Ph for pgsql-general@lists.postgresql.org; Wed, 26 Jun 2024 10:06:43 +0000 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-107.mailbox.org (Postfix) with ESMTPS id 4W8HRD3KHQz9sSM; Wed, 26 Jun 2024 12:06:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ewie.name; s=MBO0001; t=1719396392; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=83OIHV5ZkH7rT6ea8JIZrz9zM56xnSAIruepiLy8y2g=; b=gLJtDxY7E+warGltC3mIm6N9VzPjymG12/3ChFUbm5Q04Fr0GnEu8Mxi/47YROklcJGWZK 1TepuxrWXKfH6jFI+hrY45jg7QNnKT2NOYSbMDtpDP05aTtSSJsBi2ILH/oRmlf8mol7pb Hwjc8DHjGNR0Z5r93xYZcoAl9bimQBq1OIYbLoe+dHd76duT9UCS5Fzsj7qOxH508KIMcu gHFrm9014QkW3f7f6WN3wZt3zHyelfJEB7uRstTbLdEkNI7nSaB/beB+i4WwfgrXC5wYFx kJdfiFdkFjxLGdmcB9RBtf82HI+3u9joKsMzQ0ytwk7srSlfzX+KBRG0UPPiuA== Date: Wed, 26 Jun 2024 12:06:29 +0200 From: Erik Wienhold To: Dominique Devienne Cc: pgsql-general@lists.postgresql.org Subject: Re: current_role of caller of a DEFINER function Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4W8HRD3KHQz9sSM List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024-06-26 10:35 +0200, Dominique Devienne wrote: > Hi. I was led to believe (by an hallucination...) that I could know > the current_role of the caller of a DEFINER function, but after actual > experimentation, turns out it shows the OWNER of the function, and not > the current_role of the caller. > > I foolishly thought curent_role != current_user inside the DEFINER > function, but reading back the doc, it's clear current_role = > current_user = user, thus that was wishful thinking. Only session_user > is representative of the caller, and reliable (modulo SUPERUSER and > SET AUTHORIZATION, but that's a different story and kinda normal) > > 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. Have you tried capturing current_user with a function parameter and default value? https://www.postgresql.org/message-id/f82f70fd-665f-6384-5e8a-987ab9e640d3%40technowledgy.de -- Erik