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
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 |