Re: GRANT ON ALL IN schema

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <pjmodos(at)pjmodos(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GRANT ON ALL IN schema
Date: 2009-08-05 19:21:47
Message-ID: 603c8f070908051221u676e9d68ya42f5099aafb2e8e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 5, 2009 at 2:57 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> Right now we have a situation where most web developers aren't using
> ROLEs *at all* because they are too complex for them to bother with.  I
> literally couldn't count the number of production applications I've run
> across which connect to Postgres as the superuser.  We need a

I have one database that is set up with a reporting user (read only on
everything). It requires constant maintenance. Every time an object
is added or deleted (or dropped and recreated, like a view, which I do
ALL THE TIME to work around the inability to add/remove columns) the
permissions get shot to hell. I finally crontabbed a script that
fixes it every 20 minutes. I had another database where I tried to do
some real permission separation and it was just a huge pain in the
ass.

Grant on all isn't gonna fix these problems completely, but it's a
start. The DefaultACL stuff is another important step in the right
direction. Documenting how to use PL/pgsql to do this stuff is an
EXCELLENT idea, but it's not a complete substitute for providing some
usable SQL-level facilities.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-05 19:23:17 Re: the case for machine-readable error fields
Previous Message Robert Haas 2009-08-05 19:02:41 Re: CommitFest 2009-07: Closing Soon