MIME-Version: 1.0
References: 
 <2023185982.281851219.1646733038464.JavaMail.root@zimbra15-e2.priv.proxad.net>
 <1712096587.208766558.1706090901073.JavaMail.zimbra@free.fr>
 <bd4c8b8e88548d6e08220196a02c17d4fa5d2124.camel@cybertec.at>
 <EC6A3402-8271-4EA7-B6BA-1CEFEA96C749@yesql.se>
 <1327973565.212682013.1706107220766.JavaMail.zimbra@free.fr>
 <ae2b506af55afec6f3841d69c1f01aea976df619.camel@cybertec.at>
In-Reply-To: <ae2b506af55afec6f3841d69c1f01aea976df619.camel@cybertec.at>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Wed, 24 Jan 2024 08:47:06 -0700
Message-ID: 
 <CAKFQuwZjb=umdSBrW5diWDbXU25ygFzTKUON2TnfRdXmt9pjTg@mail.gmail.com>
Subject: Re: SQL command : ALTER DATABASE OWNER TO
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: gparc@free.fr, Daniel Gustafsson <daniel@yesql.se>,
	pgsql-docs <pgsql-docs@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000d8f0a7060fb2fb3c"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwZjb%3DumdSBrW5diWDbXU25ygFzTKUON2TnfRdXmt9pjTg%40mail.gmail.com>
Precedence: bulk

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

On Wed, Jan 24, 2024 at 8:35=E2=80=AFAM Laurenz Albe <laurenz.albe@cybertec=
.at>
wrote:

> On Wed, 2024-01-24 at 15:40 +0100, gparc@free.fr wrote:
> > maybe a misunderstanding of my part, but your proposed modification
> doesn't matched
> > with the current behaviour of the command as precisely the object
> privileges of the old owner are **NOT** transferred
> > to the new owner along with the ownership
>
> But that is what happens.
>
> The permissions are transferred to the new owner, so the old owner doesn'=
t
> have any privileges on the object (and, in your case, cannot connect to
> the database any more).
>
>
I dislike this change, ownership of an object is completely independent of
the grant system of privileges.  The granted privileges of the old row do
not transfer to the new owner when alter ... owner to is executed.  The
separate object attribute "owner" is the only thing that changes.  If the
old owner doesn't have any granted privileges on the modified object then
they will be left with no ability to interact with that object.  In the
case of Database the applicable interactions are Create and Connect.  The
permissions the old owner may have on any other objects in the database are
also left unaffected - such as those on a schema.  But if they have lost
the ability to Connect then actually exercising schema privileges becomes
impossible.  It really isn't any different than removing their login
attribute.

Note that since PUBLIC gets connect privileges on all databases by
default...

David J.

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif"><span style=3D"font-family:Arial,Helve=
tica,sans-serif">On Wed, Jan 24, 2024 at 8:35=E2=80=AFAM Laurenz Albe &lt;<=
a href=3D"mailto:laurenz.albe@cybertec.at">laurenz.albe@cybertec.at</a>&gt;=
 wrote:</span><br></div></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Wed, 2024-01-24 at 15:40 +0100, <a href=
=3D"mailto:gparc@free.fr" target=3D"_blank">gparc@free.fr</a> wrote:<br>
&gt; maybe a misunderstanding of my part, but your proposed modification do=
esn&#39;t matched<br>
&gt; with the current behaviour of the command as precisely the object priv=
ileges of the old owner are **NOT** transferred<br>
&gt; to the new owner along with the ownership<br>
<br>
But that is what happens.<br>
<br>
The permissions are transferred to the new owner, so the old owner doesn=
9;t<br>
have any privileges on the object (and, in your case, cannot connect to<br>
the database any more).<br><br></blockquote><div><br></div><div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">I disli=
ke this change, ownership of an object is completely independent of the gra=
nt system of privileges.=C2=A0 The granted privileges of the old row do not=
 transfer to the new owner when alter ... owner=C2=A0to is executed.=C2=A0 =
The separate object attribute &quot;owner&quot; is the only thing that chan=
ges.=C2=A0 If the old owner doesn&#39;t have any granted privileges on the =
modified object then they will be left with no ability to interact with tha=
t object.=C2=A0 In the case of Database the applicable interactions are Cre=
ate and Connect.=C2=A0 The permissions the old owner may have on any other =
objects in the database are also left unaffected - such as those on a schem=
a.=C2=A0 But if they have lost the ability to Connect then actually exercis=
ing schema privileges becomes impossible.=C2=A0 It really isn&#39;t any dif=
ferent than removing their login attribute.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">Note that =
since PUBLIC gets=C2=A0connect=C2=A0privileges on all databases by default.=
..</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif">David J.</div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif"><br></div></div></div></div>

--000000000000d8f0a7060fb2fb3c--