Date: Fri, 21 Jun 2019 13:54:45 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: allow_system_table_mods stuff
Message-ID: <20190621175444.GR2480@tamriel.snowman.net>
References: <8b00ea5e-28a7-88ba-e848-21528b632354@2ndquadrant.com>
 <CA+TgmoZfJ1Y9Zrcit9zQVTSaPugCAo=UXC8b1URJcFsqNVoxqA@mail.gmail.com>
 <20274.1561134523@sss.pgh.pa.us>
 <20190621173445.42shsd6o34qk65wt@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="TWulL6J9QifKutO7"
Content-Disposition: inline
In-Reply-To: <20190621173445.42shsd6o34qk65wt@alap3.anarazel.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


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

Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> On 2019-06-21 12:28:43 -0400, Tom Lane wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> > > A related issue is that alter_system_table_mods prohibits both stuff
> > > that's probably not going to cause any big problem and stuff that is
> > > almost guaranteed to make the system permanently unusable - e.g. you
> > > could 'SET STORAGE' on a system catalog column, which is really pretty
> > > innocuous, or you could change the oid column of pg_database to a
> > > varlena type, which is guaranteed to destroy the universe.  Here
> > > again, maybe some operations should be more protected than others, or
> > > maybe the relatively safe things just shouldn't be subject to
> > > allow_system_table_mods at all.
> >=20
> > Meh.  It doesn't really seem to me that distinguishing these cases
> > is a productive use of code space or maintenance effort.  Superusers
> > are assumed to know what they're doing, and most especially so if
> > they've hit the big red button.
>=20
> I really don't buy this. You need superuser for nearly all CREATE
> EXTENSION invocations, and for a lot of other routine tasks. Making the
> non-routine crazy stuff slightly harder is worthwhile. I don't think we
> can really separate those two into fully separate roles unfortunately,
> because the routine CREATE EXTENSION stuff obviously can be used to
> elevate privs.

I'm not sure what you're intending to respond to here, but I don't think
it's what was being discussed.

The question went something like this- if we decide that setting the
default for relpages made sense in some use-case, should a superuser
have to hit the big red button to do:

ALTER TABLE pg_class SET DEFAULT relpages =3D 100;=20

or should we just allow it?

Tom's opinion, if I followed it correctly, was 'no, that is rare enough
that it just is not worth the extra code to allow that without the big
red button, but deny everything else.'  My opinion was 'if they bring us
a legitimate use-case for such, then, sure, maybe we allow specficially
that without hitting the big red button.'  Robert was suggesting that we
could have a tri-state for a_s_t_m, where you could hit the big red
button only half-way, and certain things would then be allowed.

At least, I think that's about how it went.  None of it was about doing
typical CREATE EXTENSION and similar routine tasks that don't involve
running ALTER TABLE or DML against catalog tables.

Thanks,

Stephen

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

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

iQIcBAEBCgAGBQJdDRnkAAoJEO1sijiDR2RV3twP/jdGolYv45+De2y31i63HURj
JhhKC68wAXUgSj5OcqqRlasQCsRiPT98WmLXSgzn3h89sqFeAU1Tv1UrqV0jH7j9
haVOyrtqyJWxPuXgMhcMuCZeSpCsjsNWTfzhybRTgJPH1atxqa2DgZpSgvhksKD9
VVS0k/cNxabdD7zh4JdUFFX9skh1t0ZMHxHi1oPE+Jp+uv5g7HQBDIl4+Ea1pHr4
wC8PF3qfCKcZb5upzEarrqRjoY2EEnCuy4M/zp9rR/27+kx8kDr01uBYekqYLrSy
DiQfGxCShuOFJ6zHALsJEi9M0ityC7C/7SM0SQZ2+rrJCmP6++SBHvCFYqmIU1PS
lAfPwqXWvt8dzDBZZxlHAUwupxODDFAU6n1QH4xWkyCJ+gBeRa7RVvMjesnJWlQ2
qekU7ZN7L67djeiMvq8LUwAC2Ocw8ihBvdCDaFAu9sj0E/vw58L3uMSG0ZOeF164
iV1mFmxV5m4/zkPY2Jg/fnSa2IO//Kt6ciQLEZKfUY7YBFtBf/ymAwB2imRSQ2XK
FDV74mLXFvL11ehN5JSleX8fT2K90qUyMKEyLMqcIZr+dweQbAJ16R6AmX3OyZix
OfNfXE77gdk0HgyfqNKkDHGSfMCHL1zHCpL+nR0ESKt4QEbcZE2nquPjzSwarBSM
SJeFNfY4ts9jAN07rgda
=1YLl
-----END PGP SIGNATURE-----

--TWulL6J9QifKutO7--