Date: Sat, 28 Feb 2015 18:32:45 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Adam Brightwell <adam.brightwell@crunchydatasolutions.com>,
 Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: CATUPDATE confusion?
Message-ID: <20150228233245.GO29780@tamriel.snowman.net>
References: <28382.1419703324@sss.pgh.pa.us>
 <20141227231829.GX3062@tamriel.snowman.net>
 <1952.1419722762@sss.pgh.pa.us>
 <20141227233150.GA2046947@tornado.leadboat.com>
 <CAKRt6CTrOf6w5sE5GDRQAJ+JQrfK4h8VM=jVCtiGC+mdFsmXGg@mail.gmail.com>
 <54E65000.8030304@gmx.net>
 <20150225203955.GY29780@tamriel.snowman.net>
 <54EE8C6E.8090506@gmx.net>
 <20150226030541.GG29780@tamriel.snowman.net>
 <54F2376E.9080501@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="tB3UQx9o7itSJcWB"
Content-Disposition: inline
In-Reply-To: <54F2376E.9080501@gmx.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

Peter,

* Peter Eisentraut (peter_e@gmx.net) wrote:
> On 2/25/15 10:05 PM, Stephen Frost wrote:
> > Agreed, but I'd also like to get rid of any reason, beyond emergency
> > cases, for people to modify the catalog directly.  There's a few places
> > which we aren't yet doing that, but I'd rather fix those cases than
> > encourage people to give out rights to modify them and end up making
> > things like:
> >=20
> > "UPDATE pg_database SET datallowconn =3D false where datname =3D 'xyz';"
> >=20
> > an accepted interface.
>=20
> I'm not sure those things are related.

Eh, I feel they are, but either way.

> Getting rid of the *reasons* for updating catalogs directly might be
> worthwhile, but I don't see why we need to install (or maintain) a
> special invisible permission trap for it.  We have a permission system,
> and it works pretty well.

We have this "invisible permission trap" known as checking if you're a
superuser all over the place.  I'm not against revisiting those cases
and considering using the GRANT permission system to manage access, but
that's certainly a larger project to work on.  What I'm referring to
here are all the functions that check if you're a superuser, instead of
just revoking EXECUTE from public and letting the user manage the
permission.

> The Unix kernels don't have special traps for someone to modify
> /etc/shadow or similar directly.  That file has appropriate permissions,
> and that's it.  I think that works pretty well.

This isn't really /etc/shadow though, this is more like direct access to
the filesystem through the device node- and you'll note that Linux
certainly has got an independent set of permissions for that called the
capabilities system.  That's because messing with those pieces can crash
the kernel.  You're not going to crash the kernel if you goof up
/etc/shadow.

	Thanks!

		Stephen

--tB3UQx9o7itSJcWB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQIcBAEBCgAGBQJU8lAcAAoJEO1sijiDR2RVpPUQAME1JQ/LXO/rfZtxDMfbX1Tm
76PdhqgV74VPKYqiI7OeVQQgerlpsZ3doViQQ2rdg+eaBi6vKercLZMR2YYa/rLT
GywIB8rrxnT8HFUxj+jqgtjCCPrCcH+ZHZ7Ra/CHXtGaI2/RYqVvYuDSSanh4z+l
VV8XSwdwxsrIg8Uhu2vj8wMP0kNCvEefTorHiJKgPX338m6whowAGJqDjzsWoONk
bMsGYN9Gf+Skw8fFLFgMahYom2oq6gLCjXQ8sOVR0cmkYS3y4m/9P9bUNVfcP7Gx
THLInXVahN3cQmkjPDI8w8m9Y+USTvt3pK//TTRTbGxqBIiB6RN0tiLJZuA93yn5
TtuOjOFIFqsUlIHAuyVx61pjYHCjE5TtSd6lrBVHmMDUiOJA2qulRcaHIfhCRL1f
FXaRDr8uRhPBwBSz9M/j6J+xzV5gPJt788LWgaqWvmj5dmA7L1JjDNdSzYklNtyu
L7E2AQlI9VBQ9DuCYQml3DIoCpamHVYbDjG6DJIPDxzUZ4f7nYWks63xzhXzxXZZ
U2hs2OEnpnz04NnoRKlYmeeb+rrwrz5PMj+dPp14KhKa2TCncsdPpYDbZg9GlvqM
5vzE45+qU4tIzVT4uc83qASJEX3XUX1aOKTekUL36E1Er+igaxo/TMFU8irSjYEH
cfTSuLDfxKbHSA6m3pZf
=NkEQ
-----END PGP SIGNATURE-----

--tB3UQx9o7itSJcWB--