Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzlN1-0008CS-P5 for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jun 2022 20:36:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nzlN0-0002ve-LJ for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jun 2022 20:36:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzlN0-0002vQ-BO for pgsql-hackers@lists.postgresql.org; Fri, 10 Jun 2022 20:36:38 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzlMx-0005dV-0a for pgsql-hackers@postgresql.org; Fri, 10 Jun 2022 20:36:37 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 000B75C01E4; Fri, 10 Jun 2022 16:36:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 10 Jun 2022 16:36:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1654893391; x= 1654979791; bh=A7K4Y9F19f0JDnuypvXIJGKcdlWpQ/Zfp/zjW6jJ+tM=; b=o N/Qe3cxfOeedX1nR+2cNE5Vhqyn1nu5gUPLkCp7Vq6wfVFtFtZNn7rIc1XlZT5Ze UedNJI144CDX0RkUlai2KxRi0hlfHWWUVijLenWCSlJtCv8gWLnuEJweaQT0Texr 0Cv2yNUDwC3NX2+rGXYAhWmKz4fZyuCCyV41iDWuaoWdfXWcoOhFXSQUAUDt1D1g ehRHjgML1VEZ4AHosbTeTh+oY6rLbI23/mLnBO/ygSoFa5DK2UKJmUR8VRb5xk9E N8I6Qdxnx4tImAnIWIysXq9L0m7C7YQUmVPH4rS0i1ym0sJzQ3IHbhLjk8xex69w hZxToasxKoZ2IrFQY+c0w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudduuddgudegkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgv thgvrhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnh htvghrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepheelffeggedujeet iefhleetuddvieffhfffvdejvdffgeejkeduleduheduieefnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgr uhhtsegvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 10 Jun 2022 16:36:29 -0400 (EDT) Message-ID: <2b7b22a9-b248-4b79-abff-755b2c56100c@enterprisedb.com> Date: Fri, 10 Jun 2022 22:36:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: replacing role-level NOINHERIT with a grant-level option Content-Language: en-US To: Robert Haas , Joe Conway Cc: Tom Lane , "Bossart, Nathan" , Stephen Frost , PostgreSQL-development References: <20211108204449.GO20998@tamriel.snowman.net> <5F9388A2-35EA-4DAA-BE05-68D55EEA6DC3@amazon.com> <0ED10807-9E7F-4BB5-9473-4668EE68AE2D@amazon.com> <4117557.1641329799@sss.pgh.pa.us> <730520.1644168290@sss.pgh.pa.us> <80af9ba7-ec24-9134-8fd9-00bf13f5c494@joeconway.com> From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 02.06.22 18:26, Robert Haas wrote: > On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote: >>> It seems to me that the INHERIT role flag isn't very well-considered. >>> Inheritance, or the lack of it, ought to be decided separately for >>> each inherited role. However, that would be a major architectural >>> change. >> Agreed -- that would be useful. > Is this a kind of change people would support? I think this would create a conflict with what role-based access control normally means (outside of PostgreSQL specifically). A role is a collection of privileges that you dynamically enable (e.g., with SET ROLE). That corresponds to the NOINHERIT behavior. It's also what the SQL standard specifies (which in term references other standards for RBAC). The INHERIT behavior basically emulates the groups that used to exist in PostgreSQL. There are also possibly other properties you could derive from that distinction. For example, you could argue that something like pg_hba.conf should have group matching but not (noinherit-)role matching, since those roles are not actually activated all the time. There are also more advanced concepts like roles that are mutually exclusive so that you can't activate them both at once. Now, what PostgreSQL currently implements is a bit of a mess that's a somewhat incompatible subset of all that. But you can basically get those standard behaviors somehow. So I don't think we should break this and go into a totally opposite direction.