MIME-Version: 1.0
In-Reply-To: <6d223a4891287cfb08b720103faef2da1b5719f3.camel@cybertec.at>
References: <GV0P278MB00996776669F54A7EADB64688BFB2@GV0P278MB0099.CHEP278.PROD.OUTLOOK.COM>
 <8c533be4-5ed8-4658-86b6-212fb2d4d1a3@joeconway.com> <GV0P278MB00993C93868025F89845F58D8BFB2@GV0P278MB0099.CHEP278.PROD.OUTLOOK.COM>
 <6d223a4891287cfb08b720103faef2da1b5719f3.camel@cybertec.at>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Fri, 7 Jun 2024 07:42:31 -0700
Message-ID: <CAKFQuwaMthLY0XFtv44EBwc=nAwJO0_onACZoG0bnj9jvPBA5Q@mail.gmail.com>
Subject: PG16.1 security breach?
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: "Zwettler Markus (OIZ)" <Markus.Zwettler@zuerich.ch>, Joe Conway <mail@joeconway.com>, 
	"pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000003ec99c061a4dcf78"
Archived-At: <https://www.postgresql.org/message-id/CAKFQuwaMthLY0XFtv44EBwc%3DnAwJO0_onACZoG0bnj9jvPBA5Q%40mail.gmail.com>
Precedence: bulk

--0000000000003ec99c061a4dcf78
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Friday, June 7, 2024, Laurenz Albe <laurenz.albe@cybertec.at> wrote:

> On Fri, 2024-06-07 at 13:54 +0000, Zwettler Markus (OIZ) wrote:
> > > Another point to keep in mind is that by default, execute privilege i=
s
> granted to
> > > PUBLIC for newly created functions (see Section 5.7 for more
> information).
> >
> > Argh. No! What a bad habit!
> >
> > Might be good idea for an enhancement request to create a global
> parameter to disable this habit.
>
> I don't see the problem, since the default execution mode for functions i=
s
> SECURITY INVOKER.
>
> But you can easily change that:
>
>   ALTER DEFAULT PRIVILEGES FOR ROLE function_creator REVOKE EXECUTE ON
> FUNCTION FROM PUBLIC;
>


You named function_creator here when in this example the role creating the
new object is postgres.  How is it that the default privilege granted to
public doesn=E2=80=99t seem to care who the object creator is yet when revo=
king the
grant one supposedly can only do so within the scope of a single role?

David J.

--0000000000003ec99c061a4dcf78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Friday, June 7, 2024, Laurenz Albe &lt;<a href=3D"mailto:laurenz.albe@cy=
bertec.at" target=3D"_blank">laurenz.albe@cybertec.at</a>&gt; wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">On Fri, 2024-06-07 at 13:54 +0000, Zwettler Mar=
kus (OIZ) wrote:<br>
&gt; &gt; Another point to keep in mind is that by default, execute privile=
ge is granted to<br>
&gt; &gt; PUBLIC for newly created functions (see Section 5.7 for more info=
rmation).<br>
&gt; <br>
&gt; Argh. No! What a bad habit!<br>
&gt; <br>
&gt; Might be good idea for an enhancement request to create a global param=
eter to disable this habit.<br>
<br>
I don&#39;t see the problem, since the default execution mode for functions=
 is<br>
SECURITY INVOKER.<br>
<br>
But you can easily change that:<br>
<br>
=C2=A0 ALTER DEFAULT PRIVILEGES FOR ROLE function_creator REVOKE EXECUTE ON=
 FUNCTION FROM PUBLIC;<br>
</blockquote><div><br></div><div><br></div><div>You named function_creator =
here when in this example the role creating the new object is postgres.=C2=
=A0 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 supp=
osedly can only do so within the scope of a single role?</div><div><br></di=
v><div>David J.</div><div><br></div>

--0000000000003ec99c061a4dcf78--