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 1nShTu-0000uu-38 for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Mar 2022 15:47:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nShTs-0005Pj-UE for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Mar 2022 15:47:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nShTs-0005Pa-KW for pgsql-hackers@lists.postgresql.org; Fri, 11 Mar 2022 15:47:04 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nShTq-0006uq-88 for pgsql-hackers@postgresql.org; Fri, 11 Mar 2022 15:47:04 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 22BFktfT876566; Fri, 11 Mar 2022 10:46:55 -0500 From: Tom Lane To: Robert Haas cc: Stephen Frost , Peter Eisentraut , "David G. Johnston" , Joshua Brindle , Mark Dilger , Andrew Dunstan , PostgreSQL-development Subject: Re: role self-revocation In-reply-to: References: <0c095133-7dc7-7a11-b773-0318807380db@enterprisedb.com> <2e2f9ae2-50fc-1a03-394c-ed4288a8cae2@enterprisedb.com> <20220310195849.GH10577@tamriel.snowman.net> <20220310204156.GI10577@tamriel.snowman.net> <682134.1646950476@sss.pgh.pa.us> <20220311152752.GK10577@tamriel.snowman.net> Comments: In-reply-to Robert Haas message dated "Fri, 11 Mar 2022 10:41:17 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <876564.1647013615.1@sss.pgh.pa.us> Date: Fri, 11 Mar 2022 10:46:55 -0500 Message-ID: <876565.1647013615@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Fri, Mar 11, 2022 at 10:27 AM Stephen Frost wrote: >> I agree that there would be a recorded relationship (that is, one that >> we write into the catalog and keep around until and unless it's removed >> by an admin) between creating and created roles and that's probably the >> default when CREATE ROLE is run but, unlike tables or such objects in >> the system, I don't agree that we should require this to exist at >> absolutely all times for every role (what would it be for the bootstrap >> superuser..?). At least today, that's distinct from how ownership in >> the system works. I also don't believe that this is necessarily an >> issue for Robert's use-case, as long as there are appropriate >> restrictions around who is allowed to remove or modify these >> relationships. > I agree. The bootstrap superuser clearly must be a special case in some way. I'm not convinced that that means there should be other special cases. Maybe there is a use-case for other "unowned" roles, but in exactly what way would that be different from deeming such roles to be owned by the bootstrap superuser? regards, tom lane