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 1uh91d-00Axnm-Sr for pgsql-general@arkaria.postgresql.org; Wed, 30 Jul 2025 15:47:30 +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 1uh91c-00AfMO-KG for pgsql-general@arkaria.postgresql.org; Wed, 30 Jul 2025 15:47:28 +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 1uh91c-00AfMG-9L for pgsql-general@lists.postgresql.org; Wed, 30 Jul 2025 15:47:28 +0000 Received: from mail-oi1-x230.google.com ([2607:f8b0:4864:20::230]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uh91a-001a4p-2g for pgsql-general@lists.postgresql.org; Wed, 30 Jul 2025 15:47:27 +0000 Received: by mail-oi1-x230.google.com with SMTP id 5614622812f47-41b309ce799so4597433b6e.2 for ; Wed, 30 Jul 2025 08:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753890446; x=1754495246; 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=pP9IiVGsL82DIis2N8Uo9NZdOtOHfKtWoQXaE+bNTNo=; b=m1Bfwb8JA5nr+UB3bUbYYOarVzKJ7xDZEncFF2ScjACw2GllhHsAu8jjtFL95xSi73 YBcsXyAlu5l2BbRWzLSgA+YnHkfmLTs9w+PMnRw1PTpdHDNlK+WHNgDPuoHPumNzPA0g D86gaNNxU1zqPSW8TovqyFugbF8ZVbmmQlcZnNwIiXTMestPrj1t2l9qQ/8iMLnokkFG JeU2k2hoLsmGpwygcl9118zBaH6kCnHfw3DNXWot05wmH7PhY4PVLWHmqXWXs9spS2Cc TD4qQjSRdKHpK04reW3wdNCFlZqNVRnfESIonB7AU3YarY10+M5PDrzoqCpUe6NuoOpH oYuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753890446; x=1754495246; 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=pP9IiVGsL82DIis2N8Uo9NZdOtOHfKtWoQXaE+bNTNo=; b=lucZeZgcGQPFxetGg9Y4mqI0qUIa/ROC7hjBVVtaIqUBhCHjofiJyZxhffEoEDBaOV Tda3/vI3HT2HdbI0ZV3iX7mapvNey/vlJ+e/3nhuqdsJtmWf8/y1HbNi3J+6zSrKwOvT Fqp8lgSNg3FgUIWfW0yceVYFbDwSV3hUteGXbNwvCC3wWLNtJizNy72TfXhIkOyihYpj yDdhD7y/ixKVwe6B4QF8PeuOVY2Ska7EzgMVKLcE3LVwCyjFD346GDdzRxA/2TrrZfEM WnXnty3tuc0jGmLKEA+luCAJW7MFtsRHrpkBEU0tjj4sn21DCtE7lT1MIZBH3IGckrf4 Ve+w== X-Gm-Message-State: AOJu0YwjSxQe8YxtLvhPvShJBeVVnieMzdFgimZLR418l9nYVqDx7WCr LwOpn1nb63/FjFeykXYZRPDLUMhDvwCxE7igUNlCLSQ9n8VswwK2cxF9q4fozOKpgxcDdqM7PcQ ONfKlUBzOHeNYkZgxoLFtinuyLjjAXPkupJgY X-Gm-Gg: ASbGncvdVGhXd9MTA8B/UsaKSE3xtLHSnLRjZxblPzOjKqn+sTuNU0EkVgMOOT5o6g3 2XtORW+WXJ670499EkfRUDyYMaIkSbI75bjUIbUikedpNket9JuHUVTC0zEdesuq1wQTTZNc1pv njHHedg4IycrVZXHbDKhoPseV6p60OEPpLwxv/itqnSXvPICkRkTmH6QhtmIh1WjYVlLzIuOYub vq3BhdKMz7Em15R6nfG X-Google-Smtp-Source: AGHT+IGAVVhY8ntnNba97Gtlo70D1vjJxFKdXKHm9Rn6qIyRFIgSkJGQy5fEnne0gjnZ+IV4tZWMBChLpigIbqppoFc= X-Received: by 2002:a05:6808:2184:b0:41c:71ca:2118 with SMTP id 5614622812f47-43199f85266mr2406415b6e.11.1753890445870; Wed, 30 Jul 2025 08:47:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dominique Devienne Date: Wed, 30 Jul 2025 17:47:14 +0200 X-Gm-Features: Ac12FXyUzhW-53wBBAmRIAFqCNwl2t8xJMDSoUec2I4AMIZnRvPonujGDj6bs_o Message-ID: Subject: Re: SET LOCAL ROLE inside SECURITY INVOKER (LANGUAGE plpgsql) function To: Adrian Klaver 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, Jul 30, 2025 at 5:23=E2=80=AFPM Adrian Klaver wrote: > On 7/30/25 04:37, Dominique Devienne wrote: > > Are there special consideration I'm unaware of, regarding SET ROLE > > inside routines? > What is the ROLE that defined the function? A 3rd role. But does it matter? Given that this is in SECURITY INVOKER func= tion? > What does "My setup ensures that the role I SET LOCAL ROLE to, has > (indirectly) been granted DMLs on that table." in terms of actual GRANTs? There's a fixed ROLE (called :SOWNER) that has USAGE on the SCHEMA that owns the table. And an explicit GRANT INSERT, UPDATE, DELETE ON TABLE SchemaMapping to it. And that fixed :SOWNER ROLE is granted to the per-schema role I SET LOCAL ROLE to, WITH INHERIT TRUE. Lets call that latter role :OWNER1. So inside the function, when I `SET LOCAL ROLE :OWNER1` I expect current_role to become :OWNER1 (the raise notice corroborates that= ), which activates the :SOWNER fixed role, since it was granted WITH INHERIT T= RUE, which thus give USAGE on the table SCHEMA, and DELETE on its TABLE. Thus the DELETE DML should work... That's what I'm expecting to happen. But it doesn't. And I don't see why ye= t. The function and the table belong to yet another role. And when we enter the function, we're yet another one (obviously with USAGE+EXECUTE, since could call it). But once we SET LOCAL ROLE, the effective permissions used should be for :OWNER1 and the inherited :SOWNER.