user-defined default public acl - Mailing list pgsql-hackers

From Fabien COELHO
Subject user-defined default public acl
Date
Msg-id Pine.LNX.4.58.0404121419220.15842@sablons.cri.ensmp.fr
Whole thread Raw
Responses Re: user-defined default public acl  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@cri.ensmp.fr


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: make == as = ?
Next
From: Tom Lane
Date:
Subject: Re: 7.5 beta version