Fabien COELHO <coelho@cri.ensmp.fr> writes:
> Thus I'd like to add a user defined default public acl for postgresql
> database, namespace, class, language and proc, instead of the hardwired
> defaults in "src/backend/utils/adt/acl.c".
I'm unconvinced that this is a good idea. In the first place I am
unsure what sorts of surprising behaviors might result from
nontraditional defaults for these ACL settings. (I find the precedent
of "umask 077" unconvincing because a Unix filesystem only deals with
two kinds of objects, files and directories, with not-so-different
protection behaviors. I don't know that that scales up to SQL.)
> Also, I'm afraid that empty acl arrays (from what is seen from acl fields
> when dumping pg_database or other tables) have a meaning at the time,
> which is "default"... this may interact with new user-defined defaults.
Yup, it would, and that strikes me as another fertile place for problems.
You will have to make some basic changes in the way that default ACLs
are handled, or else such a feature would introduce security holes.
I'm not sure how much user-facing behavior would have to change, but
I doubt it could be a completely transparent change.
Another area to think about is the implications for pg_dump, and
especially the implications for reloading existing dump scripts.
If the postgresql.conf settings for default ACLs are nonstandard,
wouldn't that result in reloaded objects acquiring different ACLs
than they had before? Is that a good idea?
Before buying into all this, it would be nice to see a better rationale
than "this surprised me and it's easy to fix". The latter at least
is wrong.
regards, tom lane