
Dear hackers,

I'm used to have a "umask 077", but I cannot have that at the time with
postgresql. This fact is among the many various "surprises" I had while
discovering postgresql, and this is easy to fix.

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".


In order to do so I'm planing to add 5 new user-land pg_settings intended
to describe the default rights for "public" on new objects:

- database_default_acl
- namespace_default_acl
- class_default_acl
- language_default_acl
- proc_default_acl

The default for these would be postgresql current defaults for public acl.
The value could be integer (binary) or string (symbolic).
I think that the use of a string version would be more useful:
	proc_default_acl = "x".

Any comments?


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. I
think that it would be appropriate to have defaults set at object creation
time, so that "default" would mean "no acl", thus only super users would
be able to access such objects?

Or am I missing something on this point?? That's quite possible.

-- 
Fabien Coelho - coelho@cri.ensmp.fr

Mon, 12 Apr 2004 14:22:51 +0200 (CEST)
Fabien COELHO <coelho@cri.ensmp.fr>
user-defined default public acl
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

Mon, 12 Apr 2004 09:29:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: user-defined default public acl 