Re: ASYNC Privileges proposal

In fairness NOTIFY has only had a payload since v9 (maybe 8.4?), and the
issue of trust is mainly tied to data leaking from the payload, so I
suspect I won't be last person to request this as people re-visit NOTIFY :)
...but I totally get your point of course.

My first thought was also that having control at the channel-level would be
ideal, but that would be a huge implementation change by the looks of
things, would certainly affect performance a great deal more and would not
really give much more benefit that could be attained with database-level
control + a "SECURITY DEFINER" function.

Chris

On 20 May 2013 03:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Chris Farmiloe <chrisfarms(at)gmail(dot)com> writes:
> > 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.
>
> TBH, nobody has complained about this in the fifteen-plus years that
> LISTEN has been around. I'm dubious about adding privilege-checking
> overhead for everybody to satisfy a complaint from one person.
>
> > 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.
>
> ... and if I did think that there were an issue here, I doubt I'd think
> that a privilege as coarse-grained as that would fix it. Surely you'd
> want per-channel privileges if you were feeling paranoid about this,
> not to mention separate read and write privileges. But the demand for
> that just isn't out there.
>
> regards, tom lane
>