Re: Removing pg_pltemplate and creating "trustable" extensions
Stephen Frost <[email protected]> Mon, 13 Jan 2020 13:40:19 -0500
| Newsgroups | gmane.comp.db.postgresql.devel.general |
|---|---|
| Message-ID | <[email protected]> |
Greetings, * Tom Lane ([email protected]) wrote: > Stephen Frost <[email protected]> writes: > > To be clear, I was advocating for a NEW DB-level privilege ('INSTALL' or > > 'CREATE EXTENSION' if we could make that work), so that we have it be > > distinct from CREATE (which, today, really means 'CREATE SCHEMA'). > > I still say this is wrong, or at least pointless, because it'd be a > right that any DB owner could grant to himself. Yes, of course it is, that the DB owner would have this privilege was something you agreed to in the prior email- I'd rather not just have a "if (DBOwner())" check, I'd rather use our actual privilege system and have this be a right that the DB owner has but can then GRANT out to others if they wish to. I'm certainly not suggesting that such a privilege wouldn't be controlled by the DB owner. Forcing it to only be allowed for the DB owner and not be something that the DB owner can GRANT out isn't much better than "if (superuser())"-style checks. > If we're to have any > meaningful access control on extension installation, the privilege > would have to be attached to some other object ... and there's no clear > candidate for what. Extensions are installed at the DB level, not at any other level, and therefore that's the appropriate place to attach them, which is exactly what I'm suggesting we do here. > As someone noted awhile back, if we could somehow > attach ACLs to potentially-installable extensions, that might be an > interesting avenue to pursue. That's well beyond what I'm willing > to pursue for v13, though. Sure, having some catalog of installable extensions where someone (in my thinking, the DB owner) could GRANT out access to install certain extensions to others might be interesting, but it's not what I'm suggesting here. > In the meantime, though, this idea as stated doesn't do anything except > let a DB owner grant install privileges to someone else. I'm not even > convinced that we want that, or that anyone needs it (I can recall zero > such requests related to PLs in the past). And for sure it does not > belong in a minimal implementation of this feature. Yes, that's what this approach would do. I suppose an alternative would be to lump it in with "CREATE" rights on the DB, but I've advocated and will continue to advocate for splitting up of such broad rights. DB-level CREATE rights currently cover both schemas and publications, for example, even though the two have rather little to do with each other. If the only agreeable option is a if (DBOwner())-type check, or lumping the privilege to CREATE (trusted) EXTENSION in with other DB-level CREATE rights, then I'll go along with one of those. I'll be happy enough with that, since it avoids having an additional default role that has to be GRANT'd by a superuser. Ideally, down the road, we'll split out the CREATE privilege (both at DB and at schema level) to be more fine grained, but that can certainly be done later. Thanks, Stephen
signature.asc
(application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJeHLmTAAoJEO1sijiDR2RVmp0QAL5RTTPtyRYN/GzAhhs+04DA PaatvFSU0KqdUncXbTMYI7OOKKQAxsbjrnfsaRClBWeZkcYXJiO5JG8/O80SBKlX gvNwzEWPg7Ayd3rfKi9kxAyoEqw3mr7CNkTm7MkZfBSL9neaWRpTFr+uqUrIOBYQ ngwkHlPK/mbz+37D2J71l+bLTNfZOhmE4h7wV86QSZCMI5H1GNMtH2FVzrInRwss epqb64AIIjbFk1/rAQhK7FNYeZBcA+/dqimU7mq/AkLXbbq1SHO+PeV5MjCc9XU1 b1d6AaWIfUu4ef7o3t6K4rNo7g4IbVByooz1n2zKSBLO49h2Gb+H2w0Wq7ELlcT0 66EMkJJRtQcRA011RmRplnGJ6ofhRSbCKqdGoUSgi/H0Gd4Zd8/3SygiOjXp9j4D cKyCS33Hirev2MCkzVDb1gWVozlpo0kGpp2DjYBdphZ0Le9HeWXVVLJFvw6gFDKn vmwMENitu3ycNuvqknGqMsmgALrmvOyH4EmBMezFKPQsq9F0rYTI03Z+8ctEKoyM BkY1Z244kWEYG5JL8JdBq99urmsI7cwQFWjgZBOt3isHWdJzl9MXFr6NeZGlIbsB uXkIcKGHHGynOEwVL+z1v+U9aweomKquBNPvFBd/90DQDnzMojM6FxpFpz4uV8j4 Sj4gjKQv+u+zh5ovkIxF =T/ps -----END PGP SIGNATURE-----