Skip site navigation (1) Skip section navigation (2)

Re: Default privileges for new databases (was Re: Can't

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Rod Taylor <rbt(at)zort(dot)ca>,Ron Snyder <snyder(at)roguewave(dot)com>,Peter Eisentraut <peter_e(at)gmx(dot)net>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Default privileges for new databases (was Re: Can't
Date: 2002-08-27 15:40:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 27 Aug 2002, Bruce Momjian wrote:

> I had a good chuckle with this.  It is the type of "shoot for the moon"
> idea I would have.  Maybe I am rubbing off on you.  :-)
> The only problem I see with this solution is it makes admins think their
> template1 is safe, when it really isn't.  That seems more dangerous than
> leaving it world-writable.  I don't think accidental writes into
> template1 are common enough to add a possible admin confusion factor.
> What we really need is some mode on template1 that says, "I am not
> world-writable, but the admin hasn't made me world-non-writable, so I
> will create new databases that are world-writable".  Does that make
> sense?
> I have an idea.  Could we have the template1 per-database GUC settings
> control the writeability of databases created from template1, sort of a
> 'creation GUC setting', so we could run it on the new database once it
> is created?  That way, we could make template1 public
> non-world-writable, and put something in the template1 per-database GUC
> setting to make databases created from template1 world-writable.  If
> someone removes that GUC setting, the databases get created non-world
> writable.
> Oh, there I go again, shooting at the moon.  ;-)
> Another idea. Is there a GUC setting we could put in template1 that
> would disable writing to public for world and _couldn't_ be revoked by
> the user, except for super users?

I think your idea is good.  Is there a chance we can have a set of very 
gross permissions based on the user and the database they are connected 
to and lives on top of the other security?  I.e.  UserA can READ from 
databaseB, and READ/WRITE from/to databaseA

Then, the regular permissions live under that?  Maybe we could have a 
some system that ANDed or ORed the perms easily so it wasn't slow or 
required a lot of extra programming, and if we really wanted it to not get 
in the way, only have it apply to the template databases?

Well, if there's any good ideas in there, let me know.  :-)  

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-08-27 15:50:06
Subject: Re: heap_delete, heap_mark4update must reset t_ctid
Previous:From: Bruce MomjianDate: 2002-08-27 14:17:06

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group