Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Floris Van Nee <florisvan...@optiver.com> writes: > > This is as far as I can see the same case as what I reported a few years > > ago here: > > https://www.postgresql.org/message-id/flat/1574068566573.13088%40Optiver.com#488bd647ce6f5d2c92764673a7c58289 > > There was a discussion with some options, but no fix back then. > > Hmm, so Stephen was opining that the extension's objects shouldn't > have gotten these privs attached in the first place. I'm not > quite convinced about that one way or the other, but if you buy it > then maybe this situation is unreachable once we fix that. I'm > not sure though. It's still clear that we are making ACL entries > that aren't reflected in pg_shdepend, and that seems bad.
Would be great to get some other thoughts on this then, perhaps, as it's clearly not good as-is either. I mentioned in that other thread that recording the dependency should be done but that it's an independent issue and I do still generally feel that way, so I guess we're all mostly in agreement that the dependency should get recorded and perhaps we can just go do that. I don't see any cases of it currently, but I do still worry, as I also mentioned in the prior thread, that by allowing DEFAULT PRIVILEGES to impact extension objects that we could end up with a security issue. Specifically, if a user sets up their schema like: ALTER DEFAULT PRIVILEGES ... GRANT EXECUTE ON FUNCTIONS TO me; and then creates an extension which is marked as 'trusted': CREATE EXTENSION abc; where that extension manages function access through the GRANT system (as many do, eg: pg_stat_statements which does: REVOKE ALL ON FUNCTION pg_stat_statements_reset() FROM PUBLIC; ) That the user then will have EXECUTE rights on that function which they really shouldn't have. Thanks, Stephen
signature.asc
Description: PGP signature
