Re: ASYNC Privileges proposal

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Chris Farmiloe <chrisfarms(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ASYNC Privileges proposal
Date: 2013-05-28 13:34:57
Message-ID: 20130528133457.GC23164@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 20, 2013 at 02:44:58AM +0100, Chris Farmiloe wrote:
> Hey all,
>
> I find the current LISTEN / NOTIFY rather limited in the context of databases
> with multiple roles. As it stands it is not possible to restrict the use of
> LISTEN or NOTIFY to specific roles, and therefore notifications (and their
> payloads) cannot really be trusted as coming from any particular source.
>
> If the payloads of notifications could be trusted, then applications could make
> better use of them, without fear of leaking any sensitive information to anyone
> who shouldn't be able to see it.
>
> I'd like to propose a new ASYNC database privilege that would control whether a
> role can use LISTEN, NOTIFY and UNLISTEN statements and the associated
> pg_notify function.
>
> ie:
> GRANT ASYNC ON DATABASE xxxx TO bob;
> REVOKE ASYNC ON DATABASE xxxx FROM bob;
>
> SECURITY DEFINER functions could then be used anywhere that a finer grained
> access control was required.
>
> I had a quick play to see what might be involved [attached], and would like to
> hear people thoughts; good idea, bad idea, not like that! etc

I question the usefulness of allowing listen/notify to be restricted to
an entire class of users. The granularity of this seems too broad,
though I am not sure if allowing message to be sent to a specific user
is easily achievable.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2013-05-28 13:38:05 Re: Extent Locks
Previous Message Robert Haas 2013-05-28 13:23:33 Re: Move unused buffers to freelist