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 1sMO8S-0024YS-8u for pgsql-general@arkaria.postgresql.org; Wed, 26 Jun 2024 08:36:12 +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 1sMO8Q-002mWj-H3 for pgsql-general@arkaria.postgresql.org; Wed, 26 Jun 2024 08:36:10 +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 1sMO8Q-002mWZ-4V for pgsql-general@lists.postgresql.org; Wed, 26 Jun 2024 08:36:10 +0000 Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sMO8J-003cWP-JP for pgsql-general@lists.postgresql.org; Wed, 26 Jun 2024 08:36:09 +0000 Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-700d083b65bso300161a34.3 for ; Wed, 26 Jun 2024 01:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719390961; x=1719995761; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=yTTwDVy8rMZ+JXoIAOGmBWRvILAWYIToR+lRcYjtdMg=; b=ezOgi9fPBqLGWxdn4KjkvpdoWHJ3oAjcRoT1PSTdYniYdtEU745z0RztxznAo7gs6S +o2UsmyERxoRbcLRzIwoEr0oTF86T0A/Frt4qVjT+hmrDUY0bfviXVRdwY56WoYR7RXn RFGqeOMY6RBLEIs4yNn94OOgkka0M+/JgRHCjWJHjFVWFji0xoZ+Yh2j4C/J3fJNibqF auiZ+2lBoEa83Dez4PGEc7gwe56hSIPa8oOVtxuShOgYaPgb4YiWOVV1B8OOitII58xe WVfkl1Y37Sk3ZogBd5sfaktzgG+IrEIH9J0XoWK/anUmAmPDOyH0Ppo3/LDVl71wg9b9 wU+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719390961; x=1719995761; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yTTwDVy8rMZ+JXoIAOGmBWRvILAWYIToR+lRcYjtdMg=; b=WdcDo94eXoBoQMEOutzl+xbBwCfB/dSrQ1g6msVyyVafXOZ3B3fTAwVJEBkCXKQ7hq L+NkqehuX5sxM8xiXSE5Nyn1sfLCdksk/x9RFpIO7kkerRIM/Dxb+FpwIXTrNaJV9a21 mlbbPBDbZjMfEmriHh/RHzHwihPbT8X+Q0EVDGaJFy2H+vctU7SihkPKkNFHPnp/QT9e I4HfwmgZF+ZmMxPwBcIZ7CQ2OA08bXSJwKUArR6tnRVS4spZeEDOJP7KQuxYkoqzLoiT ghI+9ZSGmT4eHToQ47a0ZX213hP5URDrUfJfyCbY7hUuJClLX7VVfUKF9oZNlmzCE/09 DYZg== X-Gm-Message-State: AOJu0YzlXw5V0bVjysn5i0zQvkKh9etKFzZ7P5O1XtC/TasRYzbkULf4 YzVnQDGSWvMEPlsgjXsBbrQAUhKgZdBJCA/bzBpOWw7x1uG+nT3JcvidgCZFhl9k2R+b/fLl3yx tUlrlnXMthj89UGbGP7nsDDI2NGaYvg== X-Google-Smtp-Source: AGHT+IFB0IbR4X7wx3CHdsxvY4eaN/MkVvfIMvk2dnJRQzAoJjmeG5GhJvzyU9yp0dVuLJnPtrSq/trinqwPCkOcHSo= X-Received: by 2002:a05:6870:8594:b0:25c:bc3f:f936 with SMTP id 586e51a60fabf-25d016724cdmr11221773fac.5.1719390960731; Wed, 26 Jun 2024 01:36:00 -0700 (PDT) MIME-Version: 1.0 From: Dominique Devienne Date: Wed, 26 Jun 2024 10:35:49 +0200 Message-ID: Subject: current_role of caller of a DEFINER function To: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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. 2) Why isn't there a way to obtain the above? What harm would it be? Obviously for #2, distinguishing current_role from current_user inside DEFINER is a no-go, for backward compatibility. But could a new variable be invented for that? What obvious technical reason I'm missing would make that harmful or difficult? As to the use-case, now that I have a queue mechanism for tasks to be delegated to services, I need to make sure the poster of the task has the right privileges, so I wanted to capture session_user and current_role of the "poster", and the service would use that info, reliably captured (inside the DEFINER function to post a task), using ROLEs and GRANTs and other app-specific permission data. LOGIN users have different persona in the system, so the current_role matters, to determine whether the connection posting the task to be processed asynchronously by a service is allowed or not. I'd think I'm not the only one that would need something like this, no? Thanks, --DD