Re: Default privileges for new databases (was Re: Can't - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Default privileges for new databases (was Re: Can't
Date
Msg-id 18839.1030421298@sss.pgh.pa.us
Whole thread Raw
In response to Re: Default privileges for new databases (was Re: Can't  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Default privileges for new databases (was Re: Can't  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> So template1 is writable (yuck) only so databases created from template1
> are writeable to world by default.  Is that accurate?

Yup.

I had a probably-harebrained idea about this: the writeability of public
is only a serious issue when it is the default creation-target schema.
It's likely that you'd say "create table foo" without reflecting about
the fact that you're connected to template1; much less likely that you'd
say "create table public.foo".  So, what if the default per-database GUC
settings for template1 include setting the search_path to empty?  That
would preclude accidental table creation in template1's public schema.
As long as CREATE DATABASE doesn't copy the per-database GUC settings of
the template database, copied databases wouldn't be similarly crippled.

Now I'm not entirely convinced that CREATE DATABASE shouldn't copy the
per-database GUC settings of the template.  But at the moment it
doesn't, and if we're willing to institutionalize that behavior then
it'd provide a way out.

Or is that too weird?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Use of LOCAL in SET command
Next
From: Tom Lane
Date:
Subject: Re: Use of LOCAL in SET command