Stephen Frost <sfrost@snowman.net> writes:
> In particular- should we really be setting default privileges for objects
> that are being created by an extension, at all? The more I think about it,
> the less I like it, particularly when we start to think about the trusted
> extension work that Tom’s doing.
> In short, I’m leaning towards the argument that this was a missing check in
> the default ACL code to explicitly *not* add default privileges on objects
> that are being created by an extension. With such a check, the entire
> wouldn’t end up in pg_init_privs and the issue that started this thread
> wouldn’t happen.
Hmm. I think we'd still wish pg_upgrade to preserve whatever privileges
have been granted on extension objects, but that doesn't necessarily
have to happen through pg_init_privs. I've forgotten the details ---
would the change you suggest be enough to make upgrade work correctly,
or would we need additional hacking?
Err, privileges on upgrade *are* preserved, even with this. Guess I wasn’t clear.
Right now:
If someone sets up default privileges for a user, and that user then creates an extension, the default privs are applied to all of the individual objects that are created by the extension, and then get recorded in pg_init_privs, as if it was the extension setting up those privileges.
Having those privileges end up in pg_init_privs is pretty clearly wrong because only those privileges that are installed by the extension should end up in init privs, because all OTHER privileges are what will be dumped out.
However, I’m not sure that those objects, which are inside the extension, should really be having default privs applied to them in the first place! If I have default privs set up to grant EXECUTE to some user on functions, and then I install pg adminpack, is it really right for all the functions in pg adminpack to now have execute rights granted to whomever this user is- even when the extension revoked the grant to public because the function is unsafe for general users to have access to..?
I feel like default privs should apply when the user is EXPLICITLY creating a specific object, not when it’s being created as part of an extension, and therefore we should have a check in the creation system, where the default privs are handled, to basically make the default privs code be a no-op when the object is being created by an extension. Users will have to go grant access to those objects in the extension explicitly instead, but that seems perfectly reasonable to me.
Currently traveling and so not actually looking at the code, but that’s my recollection of things.
Thanks,
Stephen