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 1qdwPO-005EdU-9D for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Sep 2023 17:33:42 +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 1qdwPM-00C2I6-AR for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Sep 2023 17:33:40 +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 1qdwPL-00C2Hl-WB for pgsql-hackers@lists.postgresql.org; Wed, 06 Sep 2023 17:33:39 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qdwPI-00367i-N8 for pgsql-hackers@postgresql.org; Wed, 06 Sep 2023 17:33:38 +0000 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1bee82fad0fso398105ad.2 for ; Wed, 06 Sep 2023 10:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694021615; x=1694626415; darn=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=OK4NpW2YOb8byU7wdPYloZUmR4b0vK4WdVDgNDR6WQg=; b=ckVAIFZvRKnswM3gtGrTc2jQYvncCuuAfBvAeiZml1JEIbxv1Noo1uNhu1Nl02nH/4 laEzRcsbdo8BIy7MWHZfYXGXjYG1MMXgusLb+idcDfWbM9ZWoOX5OqmHJG+M9ASBw4QL Q2RYFDjoUX2mEPeyFoApLUXKfKJXb4pOnIGpExmOsjRNV+PrwZfhuVQpOl2Z2bR5JKmv eZPeYpgl4tx36ZGVCFAk4FVjXgDGqmsxCdnYAAWLPJNBLhwm0YGHSe3HrDZtFd5QG1Rx 8vl/FzKftk/iqY/1DxpfMrfdRDK/LGxTdpCAnhQKk3mcTrQrqqeS7OW+hq5WfY0jvZc2 NuOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694021615; x=1694626415; 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=OK4NpW2YOb8byU7wdPYloZUmR4b0vK4WdVDgNDR6WQg=; b=l3ccXFFALOwo4mWnjmlBF3qpYOJkcODZWvhPXNPIECnQbouMUX9iKQXEvMnBM78S7M mI2cqhOW5yb8rnpETFQxadwkAUDDH0slQK82Mpl7T00PRQmCvTRccmcm2cv3MDRtQLiO DjpcNVn5LpxgAztyjwFGM2qq/usFR4/yebdYSuSAFjPBVkfDC+3yPg3Vq+K3I+WwlZBa /sLFxwewSxPCGCnUoi5JbvpWITzewYxLtuwffVQWzDhs3w/1Gn/0HFUO8Wm24GtGKblc IAg8yen3aqRCUVeDUCTq1zdeF6xao9PW6Eo5ZFBx464dEtMKW73D4LIw9wFTB4auC5cC ThSA== X-Gm-Message-State: AOJu0YyPaRfvpuUd9t1hqK5pGVtiNq09bpS4ZY8RKV2cSTQYb+g3bhUg vW0s+MejgfE9BoEKkQvvbjk0TiQVwdsTlvJq9SU= X-Google-Smtp-Source: AGHT+IF+oMCOwA96xkgV3XNQOMKQTRgoZkeTLRp1z4bMWi8Gnlp0/OlWPdFmWCXqFXWLDmfsZRRaWqe07CYva4/48yk= X-Received: by 2002:a17:90a:8545:b0:268:10a3:cea8 with SMTP id a5-20020a17090a854500b0026810a3cea8mr13521410pjw.9.1694021615353; Wed, 06 Sep 2023 10:33:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ashutosh Sharma Date: Wed, 6 Sep 2023 23:03:23 +0530 Message-ID: Subject: Re: Can a role have indirect ADMIN OPTION on another role? To: Robert Haas Cc: pgsql-hackers 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, Sep 6, 2023 at 9:03=E2=80=AFPM Robert Haas = wrote: > > On Wed, Sep 6, 2023 at 11:14=E2=80=AFAM Ashutosh Sharma wrote: > > In PG-16, I see that we have made a lot of changes in the area roles > > and privileges. I have a question related to this and here is my > > question: > > > > Let's say there is a roleA who creates roleB and then roleB creates > > another role, say roleC. By design, A can administer B and B can > > administer C. But, can A administer C although it has not created C? > > Ultimately, yes, because A can get access to all of B's privileges, > which include administering C. However, A might or might not have B's > privileges by default, depending on the value of createrole_self_grant > in effect at the time when B was created. So, depending on the > situation, A might (or might not) need to do something like GRANT > roleB to roleA or SET ROLE roleB in order to be able to actually > execute the administration commands in question. > > IMHO, it really couldn't reasonably work in any other way. Consider > that A's right to administer B includes the right to change B's > password. If the superuser wants users A and B that can't interfere > with each other, the superuser should create both of those accounts > themselves instead of letting one create the other. > Thank you for the clarification. This is very helpful. Actually I have one more question. With this new design, assuming that createrole_self_grant is set to 'set, inherit' in postgresql.conf and if roleA creates roleB. So, in this case, roleA will inherit permissions of roleB which means roleA will have access to objects owned by roleB. But what if roleB doesn't want to give roleA access to the certain objects it owns. As an example let's say that roleB creates a table 't' and by default (with this setting) roleA will have access to this table, but for some reason roleB does not want roleA to have access to it. So what's the option for roleB? I've tried running "revoke select on table t from roleA" but that doesn't seem to be working. the only option that works is roleA himself set inherit option on roleB to false - "grant roleB to roleA with inherit false;" -- With Regards, Ashutosh Sharma.