On 08/28/2012 10:42 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/28/2012 09:09 PM, Craig Ringer wrote:
Wouldn't that render the user utterly unable to do anything until you
added a bunch of GRANTs on the system catalogs for that user or a
group they're a member of?
Try it and see. You ca
Andrew Dunstan writes:
> On 08/28/2012 09:09 PM, Craig Ringer wrote:
>> Wouldn't that render the user utterly unable to do anything until you
>> added a bunch of GRANTs on the system catalogs for that user or a
>> group they're a member of?
> Try it and see. You can do a lot without having any
On 08/28/2012 09:09 PM, Craig Ringer wrote:
On 08/29/2012 01:25 AM, David Fetter wrote:
Folks,
There are situations where a "default deny" policy is the best fit.
To that end, I have a modest proposal:
REVOKE PUBLIC FROM role;
Thenceforth, the role in question would only have access to
On 08/29/2012 01:25 AM, David Fetter wrote:
Folks,
There are situations where a "default deny" policy is the best fit.
To that end, I have a modest proposal:
REVOKE PUBLIC FROM role;
Thenceforth, the role in question would only have access to things it
was specifically granted.
Wouldn'
David,
* David Fetter (da...@fetter.org) wrote:
> There are situations where a "default deny" policy is the best fit.
That's certainly true. It's also what we *have*. The only places where
we aren't "default deny" are places where things have been granted to
"public".
Feel free to revoke "publ
David Fetter writes:
> There are situations where a "default deny" policy is the best fit.
> To that end, I have a modest proposal:
> REVOKE PUBLIC FROM role;
Neither possible nor sensible. PUBLIC means everybody, and is
implemented in a way that doesn't allow any other meaning.
We pretty
Folks,
There are situations where a "default deny" policy is the best fit.
To that end, I have a modest proposal:
REVOKE PUBLIC FROM role;
Thenceforth, the role in question would only have access to things it
was specifically granted.
What say?
Cheers,
David.
--
David Fetter http://fett
