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 1qLpPl-000mWp-1t for pgsql-docs@arkaria.postgresql.org; Tue, 18 Jul 2023 18:27: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 1qLpPj-00C8mj-4A for pgsql-docs@arkaria.postgresql.org; Tue, 18 Jul 2023 18:27:11 +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 1qLpPi-00C8gv-ST for pgsql-docs@lists.postgresql.org; Tue, 18 Jul 2023 18:27:10 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qLpPg-000Aqr-Df for pgsql-docs@lists.postgresql.org; Tue, 18 Jul 2023 18:27:09 +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 36IIR6nr074949; Tue, 18 Jul 2023 14:27:07 -0400 From: Tom Lane To: shen@oneshen.com cc: pgsql-docs@lists.postgresql.org Subject: Re: CREATEROLE Inheritance In-reply-to: <168968649532.632.17678694767510635173@wrigleys.postgresql.org> References: <168968649532.632.17678694767510635173@wrigleys.postgresql.org> Comments: In-reply-to PG Doc comments form message dated "Tue, 18 Jul 2023 13:21:35 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74947.1689704826.1@sss.pgh.pa.us> Date: Tue, 18 Jul 2023 14:27:06 -0400 Message-ID: <74948.1689704826@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Doc comments form writes: > I have checked this for CREATEROLE and this role attribute is definitely > inheritable. Does not look like that to me: regression=# create user alice createrole; CREATE ROLE regression=# create user bob; CREATE ROLE regression=# \c - alice You are now connected to database "regression" as user "alice". regression=> create user charlie; -- should succeed CREATE ROLE regression=> \c - bob You are now connected to database "regression" as user "bob". regression=> create user delta; -- should fail ERROR: permission denied to create role DETAIL: Only roles with the CREATEROLE attribute may create roles. regression=> \c - postgres You are now connected to database "regression" as user "postgres". regression=# grant alice to bob; GRANT ROLE regression=# \c - bob You are now connected to database "regression" as user "bob". regression=> create user delta; -- still fails ERROR: permission denied to create role DETAIL: Only roles with the CREATEROLE attribute may create roles. regression=> set role alice; SET regression=> create user delta; -- now it works CREATE ROLE (Those DETAIL messages are fairly new, but the behavior is the same in older branches.) The point is precisely that bob can't make use of alice's CREATEROLE bit without having done SET ROLE. It's not too clear to me what you did that led you to conclude otherwise, but going through additional layers like an IDE could well be confusing matters. regards, tom lane