Re: "default deny" for roles

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: David Fetter <david(at)fetter(dot)org>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "default deny" for roles
Date: 2012-08-29 01:09:40
Message-ID: 503D6BD4.6070003@ringerc.id.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Is that the idea? To restrict system catalog access?

You'd have to GRANT every function, every INFORMATION_SCHEMA and
pg_catalog entry, etc. Is that really your intention?

All public gets by default is:

- CONNECT, TEMPORARY on databases
- USAGE on trusted PLs
- USAGE on schema
- EXECUTE on functions

as per http://www.postgresql.org/docs/9.1/static/sql-grant.html:

----
Depending on the type of object, the initial default privileges might
include granting some privileges to PUBLIC. The default is no public
access for tables, columns, schemas, and tablespaces; CONNECT privilege
and TEMP table creation privilege for databases; EXECUTE privilege for
functions; and USAGE privilege for languages. The object owner can of
course revoke these privileges.
----

This *doesn't* mention the system catalogs, which it perhaps should, but
otherwise makes it pretty clear that `public` doesn't get to do much.

--
Craig Ringer

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2012-08-29 01:25:27 Re: 64-bit API for large object
Previous Message Christopher Browne 2012-08-28 21:30:53 Re: Audit Logs WAS: temporal support patch