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. :-)
