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 1sHUhW-008Esh-67 for pgsql-general@arkaria.postgresql.org; Wed, 12 Jun 2024 20:36:10 +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 1sHUhS-006jvE-LJ for pgsql-general@arkaria.postgresql.org; Wed, 12 Jun 2024 20:36:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHUhS-006juV-6D for pgsql-general@lists.postgresql.org; Wed, 12 Jun 2024 20:36:07 +0000 Received: from mail-oo1-xc30.google.com ([2607:f8b0:4864:20::c30]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sHUhM-001LQJ-EC for pgsql-general@lists.postgresql.org; Wed, 12 Jun 2024 20:36:06 +0000 Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-5b97a9a9b4bso181914eaf.0 for ; Wed, 12 Jun 2024 13:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718224558; x=1718829358; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0ZnAFdxLYUbBdZ9YNwvZQrzhcDxlEmGqW64cAMcytI4=; b=nMnbPd2Za7LjGS+IlVnoNlxi386+SKVNb4SBWYvjx8Uxqr/YfdUKpRPOS6UM6PAPgv yeCsp7LJ1iYWFn5j7y11brDdizpE95mspbNvel5gwAMwWvP1TG34O6BhqkrsCkUIEN4y iz5HTNDCoWbiy0G4d5gPVfRtCVBWL1N1cafUPBrWVW0qukff/vQ6b/w12Tw1vnZZAxC5 2pLboOp+aTl+aKud8768vHr8Ad2Dl5IsDqZT2PAR1abUsojJ3waC7dV812CjZXKZ1W9u 7p6KuqHbhwN83MMIrfV7L4vo8FeRNsmT6BO1KmTPdZb5+FkW9Nml+1l8XOZBMUESovxm 7fxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718224558; x=1718829358; h=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=0ZnAFdxLYUbBdZ9YNwvZQrzhcDxlEmGqW64cAMcytI4=; b=bGMzQxaYWQK3Si9HxFox0YWj7uukFxFs/nF8ipXd7SXpInpUHbw44CJWjwSHT0Bfvw uY2tyXJx1PlFLo8ulmFCQGn4ecs0Jw3eobtReCco1AMdyGldklbstWXSWC1PXdsLS6Kf vMaR0M2enGzREaXKnFnmrmnzvYInOxWRViq3hXcATr/LLLwcmsHR39gTbSQYiTU6Elrh ZzVhXnwScmfF8aNZ5VrC9P1YqWEht3XdCG1eAgqHGCdia6rf9rCwmbsVkMgPSryhiifi 63FH/vM+L0AKSQb4GZnRmB1xZg2DJU1mpWjPR8NsM4nlwcueHeR208dfsF53jVFzzd2x RZGA== X-Forwarded-Encrypted: i=1; AJvYcCU+DF481a+ue5Yq2rFkQJe97W0UyBVAHwUM/cgF+88Qwg2cH/Ebr1igaIcaj1SKF8KFIIKcRmujnaLRizk8x7tVa3c1LAyF9zhl+qqYcCWfI/G7 X-Gm-Message-State: AOJu0YwhcBmyy7W3DGtHl1FaXFBnPy8c4c/hu7Y72ADIJ9woeziZx5gZ 4NY0j9zPYkdsEM9wiK6yZ2VN3RV/wLrnmEzau8kk8yotvNQX3lDFbOKen495cy/hZfiLhyl0SQS /EBakATZUzrZMULC8w6ItEEEprB4= X-Google-Smtp-Source: AGHT+IFoikRSlTFQMH19jGdzei2r/6jZE4wCvH4RNU0qLbz5vjHRgbfv1Gm/ohqGyopJgqWT+gr4Tl+kym9pEHWBTD0= X-Received: by 2002:a05:6820:806:b0:5ba:cb03:2a13 with SMTP id 006d021491bc7-5bb3b7b7d63mr3295474eaf.0.1718224558195; Wed, 12 Jun 2024 13:35:58 -0700 (PDT) MIME-Version: 1.0 References: <8c533be4-5ed8-4658-86b6-212fb2d4d1a3@joeconway.com> <6d223a4891287cfb08b720103faef2da1b5719f3.camel@cybertec.at> <416045c0e7deac5b9f25e5fc89beec2a702a0b4c.camel@cybertec.at> In-Reply-To: <416045c0e7deac5b9f25e5fc89beec2a702a0b4c.camel@cybertec.at> From: "David G. Johnston" Date: Wed, 12 Jun 2024 13:35:21 -0700 Message-ID: Subject: Re: PG16.1 security breach? To: Laurenz Albe Cc: "Zwettler Markus (OIZ)" , Joe Conway , "pgsql-general@lists.postgresql.org" Content-Type: multipart/alternative; boundary="0000000000006f8b13061ab754c9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006f8b13061ab754c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2024 at 2:21=E2=80=AFAM Laurenz Albe wrote: > > How is it that the default privilege granted to public doesn=E2=80=99t = seem to > care who the object creator > > is yet when revoking the grant one supposedly can only do so within the > scope of a single role? > > I don't understand what you wrote. ALTER DEFAULT PRIVILEGES also only > applies to objects > created by a single role when you grant default privileges. > > I think my point is that a paragraph like the following may be a useful addition: If one wishes to remove the default privilege granted to public to execute all newly created procedures it is necessary to revoke that privilege for every superuser in the system as well as any roles that directly have create permission on a schema and also those that inherit a create permission on a schema. Lastly, any new roles created in the future with direct or indirect create permission on a schema must also be altered. In other words, the first time a role creates a routine the default privileges involved with that creation will including granting execute to public, unless said default privileges have already been revoked. Maybe generalized to any of the default privileges. I find the existing wording to gloss over the fact that one cannot just decide up front they want to not allow these default privileges to public once on a system-wide basis but must continually maintain the default privileges as new roles are added that are allowed to create different objects, directly or otherwise. David J. --0000000000006f8b13061ab754c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2024 at 2:21=E2=80=AFAM Laurenz Albe <<= a href=3D"mailto:laurenz.albe@cybertec.at">laurenz.albe@cybertec.at>= wrote:
> How is it that the default privilege = granted to public doesn=E2=80=99t seem to care who the object creator
> is yet when revoking the grant one supposedly can only do so within th= e scope of a single role?

I don't understand what you wrote.=C2=A0 ALTER DEFAULT PRIVILEGES also = only applies to objects
created by a single role when you grant default privileges.


I think my point is that a paragraph like the follow= ing may be a useful addition:

If one wishes to remove = the default privilege granted to public to execute all newly created proced= ures it is necessary to revoke that privilege for every superuser in the sy= stem as well as any roles that directly have create permission on a schema = and also those that inherit a create permission on a schema.=C2=A0 Lastly, = any new roles created in the future with direct or indirect create permissi= on on a schema must also be altered.=C2=A0 In other words, the first time a= role creates a routine the default privileges involved with that creation = will including granting execute to public, unless said default privileges h= ave already been revoked.

Maybe generalized to any of = the default privileges.=C2=A0 I find the existing wording to gloss over the= fact that one cannot just decide up front they want to not allow these def= ault privileges to public=C2=A0once on a system-wide basis but must continu= ally maintain the default privileges as new roles are added that are allowe= d to create different objects, directly or otherwise.

= David J.



--0000000000006f8b13061ab754c9--