From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | user-defined default public acl |
Date: | 2004-04-12 12:22:51 |
Message-ID: | Pine.LNX.4.58.0404121419220.15842@sablons.cri.ensmp.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)cri(dot)ensmp(dot)fr
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-12 12:35:16 | Re: 7.5 beta version |
Previous Message | Fabien COELHO | 2004-04-12 12:15:56 | Re: make == as = ? |