Date: Fri, 11 Mar 2022 10:32:07 -0500
From: Stephen Frost <sfrost@snowman.net>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Joshua Brindle <joshua.brindle@crunchydata.com>,
	Mark Dilger <mark.dilger@enterprisedb.com>,
	Andrew Dunstan <andrew@dunslane.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: role self-revocation
Message-ID: <20220311153207.GL10577@tamriel.snowman.net>
References: <CAKFQuwbmx9bSu6iob-k88APFZtzvPVmXFjAjdR0u3MqR3TWzzg@mail.gmail.com>
 <CA+TgmobHD6zVgRnNrz-7=Wm6W-76Q4Qrrif4zmhk522G5ay9Fw@mail.gmail.com>
 <0c095133-7dc7-7a11-b773-0318807380db@enterprisedb.com>
 <CA+Tgmobbnro+Z-uFZCGr_y6wq8gANo8EaYSvcZK2kekDdtFaZA@mail.gmail.com>
 <2e2f9ae2-50fc-1a03-394c-ed4288a8cae2@enterprisedb.com>
 <CA+Tgmoa5+pfDeuAjPtk=pKF2a63X9UoUkWBmbzR56FGoBvD_7g@mail.gmail.com>
 <20220310195849.GH10577@tamriel.snowman.net>
 <CAKFQuwZ0AD+9Yucdt_cvq5qyh_3FuWkXUgT3cX1J5E4aKk5p6Q@mail.gmail.com>
 <CA+TgmoaCpYSvgvVi5ug__02LOEijsf2yAQOBUoxf1EBtoWEHXw@mail.gmail.com>
 <CAKFQuwY9FdLfQP-f0_5eDGDfHwjrKxFLut6wHnOVF+N4Y1uuaw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="txKCGZfNyLhwRtdd"
Content-Disposition: inline
In-Reply-To: <CAKFQuwY9FdLfQP-f0_5eDGDfHwjrKxFLut6wHnOVF+N4Y1uuaw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://www.postgresql.org/message-id/20220311153207.GL10577%40tamriel.snowman.net>
Precedence: bulk


--txKCGZfNyLhwRtdd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* David G. Johnston (david.g.johnston@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 3:01 PM Robert Haas <robertmhaas@gmail.com> wrote:
>=20
> > On Thu, Mar 10, 2022 at 4:00 PM David G. Johnston
> > <david.g.johnston@gmail.com> wrote:
> > > I dislike changing the documented behavior of CREATEROLE to the degree
> > suggested here.  However, there are three choices here, only one of whi=
ch
> > can be chosen:
> > >
> > > 1. Leave CREATEROLE alone entirely
> > > 2. Make it so CREATEROLE cannot assign membership to the predefined
> > roles or superuser (inheritance included), but leave the rest alone.  T=
his
> > would be the hard-coded version, not the role attribute one.
> > > 3. Make it so CREATEROLE can only assign membership to roles for which
> > it has been made an admin; as well as the other things mentioned
> > >
> > > Moving forward I'd prefer options 1 or 2, leaving the ability to
> > create/alter/drop a role to be vested via predefined roles.
> >
> > It sounds like you prefer a behavior where CREATEROLE gives power over
> > all non-superusers, but that seems pretty limiting to me.
>=20
> Doh!  I edited out the part where I made clear I considered options 1 and=
 2
> as basically being done for a limited period of time while deprecating the
> CREATEROLE attribute altogether in favor of the fine-grained and predefin=
ed
> role based permission granting.  I don't want to nerf CREATEROLE as part =
of
> adding this new feature, instead leave it as close to status quo as
> reasonable so as not to mess up existing setups that make use of it.  We
> can note in the release notes and documentation that we consider CREATERO=
LE
> to be deprecated and that the new predefined role should be used to give a
> user the ability to create/alter/drop roles, etc...  DBAs should consider
> revoking CREATEROLE from their users and granting them proper memberships
> in the predefined roles and the groups those roles should be administerin=
g.

I disagree entirely with the idea that we should push the out however
many years it'd take to get through some deprecation period.  We are
absolutely terrible when it comes to that and what we're talking about
here, at this point anyway, is making changes that get us closer to what
the spec says.  I agree that we can't back-patch these changes, but I
don't think we need a deprecation period.  If we were just getting rid
of CREATEROLE, I don't think we'd have a deprecation period.  If we need
to get rid of CREATEROLE and introduce something new that more-or-less
means the same thing, to make it so that people's scripts break in a
more obvious way, maybe we can consider that, but I don't really think
that's actually the case here.  Such scripts as will break will still
break in a pretty clear way with a clear answer as to how to fix them
and I don't think there's some kind of data corruption or something that
would happen.

Thanks,

Stephen

--txKCGZfNyLhwRtdd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJiK2t3AAoJEO1sijiDR2RVUUgP/jqRcpwoXlTAQi01to76T8W9
KgnU5RxV57fZtvVmpd3QOvbnEadqaF6dOd8pzr9Q/voXCYHZxTEtmwCK2x5Wqx2i
q+rqWiVRExsxtBL3lBDbbcxIPIsstRHuov80GDsYaCeKZYRiA+XQvbGrNrRYWqvy
iNN489y8th5gjgarPTGRdzXOUuHscEPT+e83YKCZKzrmQtdT7UI7Sc97ByNgalBB
kCIhCGSJGcAAvQVlZPqPHjAzC3DhkrD4eKQuwaeazuUS71u28Hwn6agtph6U4D4d
Pfj2dDnuAG6IzNtWtGkzr9O4aAH1HobrbEixxeA8mk2ctmArKBrhOHDCVQ8Ulpu3
ztyuoMrK6DKLG3sJGJDACM4O1GnNQFs3JvatOEGAk5UWJKxPaFoOvNc5d6Of7viI
QodPC2rhYUB+Ron9EWq1VNtaNvTiuVaCcfxyzBrhkti1UE9n3tBhujtDP2743p5W
GpL7XbQd/VC/Yhj47Hr9WbBXghsVtZYjLNE99veP2CK5fHlp/7Sv7yVMwVCrTI6m
Wyh+DM7dZDKxgnl0j0HhaRSkTcgvhfPPAA6HnC4T61KoRnvl+6xMF6zML/acEsho
Eu67JxRBj8frPDRCir1k4CzbYrHPbeTbvZiQNPTMYtQ5dgQLThKEnSHNEkQmOlOb
W6CW52CYB7w1rfUynLFE
=3bUl
-----END PGP SIGNATURE-----

--txKCGZfNyLhwRtdd--